Updating WCF chat continues slowly but surely. I have not made any commits yet, so you’ll have to wait to see the changes.
In addition to the changes to Authentication, there are changes to the callback mechanism that I originally wrote.
When i originally wrote the chat application, the callback was one of the first pieces of code that i wrote. The fact of the matter is, the the only requirement for it was to work across the local network (or even simply between instances on the local machine). So when I wrote the Cloud version, suddenly callbacks had to work across NAT to let the application function across the internet.
Now, there are a number of possible design patterns that would allow the server to execute a callback on a remote client.
The first is ,indeed, the design pattern we use at the moment. Where we actually have a callback. the enabler for this is actually found in WCF. The wsHTTPDuplexBinding allows for dual HTTP connections – one in each direction. This allows you to invoke an operation on the client. However, in order for this to work, you need to have an instance of WCF server on a per-instance basis. So. Every new client session will spawn a new instance of the server. This means that you are going to end up with dozens ( or hundreds etc) of long-lived instances. The question here is scalability. Is this scalable?
It might seem somewhat arrogant to talk about scalability, but if you design with scalability in mind, you’re not going to end up dealing with it later.
The other is something that, while not new, really hit the big-time after Friendfeed released its Tornado server. Tornado supports long polling http connections. Long polling is not in and of itself new. The basic design pattern involves a client making a call ( http or otherwise) to a server. The server receives the connection and keeps it open until it has something to return. Some long polled connections eventually time out and this is the implicit signal for the client to immediately open another connection. Others, such as the Friendfeed implementation, keep them open indefinitely.
There are probably more that you can think of, but these are the two that I considered for the Chat Application. As with most things, the choice is between a Push model (where notifications are pushed to the client) and the Pull model (where information, Notifications or otherwise, is pulled from the server by the client).
The fact of the matter is that I like both. Both are Cool. And both are supported intrinsically by WCF – no coding voodoo to make thins work.
Of the two, I’ve begun implementing the long polling method. Although it s radical departure, it will allow the overall design of to server-side to remain the same. The WCF server remains as a Single Instance service, and so the implementation remains the same.
The WCF stack is written in such a way that when you mark a OperationContract as needing the Async Pattern, WCF with start the Asyc operation and then go off and handle another request until that method returns. The End method that receives the results then returns the data to the client. In other words, its non-blocking.
I’ve not sorted out the exact specifics of implementation, but there will be changes to both the server and the client to accommodate this. In saying that, I’m doing a lot of simplification to the class structure. So hopefully what emerges from all these changes will be better than the current setup. Even I had to go back and follow the inheritance tree to figure things out.
These changes are happening in parallel with the changes to the authentication scheme.
So, while I’ve got no code, I leave you with this MSDN blog post on Async programming with WCF and this post that adapts it to long-polling specifically.
No, I Haven’t been able to make in any changes sine my last comit.
However, I have been taking a look at it over the past week, since there are issues with it. As you say authentication and authorisation are one of them.
I’ve been looking at the possibility of using Forms authentication. This brings ASP.Net Membership, Profiles and Roles to the table and these can be used.
This of course requires a SQL server as a back end. And requires the use of SSL.
This requires significant changes to the code base, to move from the current storage model (XML in the case of the Windows service, and Azure Tables in the case of the Windows Azure role). And since authorisation and authentication are now handled separately, those WCF method calls that currently handle this aren’t required.
Also, since the codebase is effectively two separate projects, these changes need to be made twice.
The client will also need to be changed.
These changes do make a lot of sense and I’m well along in implementing them. So look out for a post soon on them.
I thought I’d let everyone know that this is the direction I’m taking things in.
Life is busy, which why I haven’t been able to update things as much as I’d like.
There is one other particular problem with the WCF Server chat that I would have liked to have solved in my last comitt.
The issue involves the server pinging other clients across NAT. Of course, this could be solved by moving to a pull model rather than a push notification model. While that would be easy, I want to take a good long look at getting push to work properly before trying any other models.
Push notification is where its at. So if anyone has any pointers to implementing it, please send it my way.