Sockets Vs. WCF

Question

I work on a chat-like application, where I use Silverlight on the client side and wpf on the server side. Right now the communication is based on Sockets: I have different Message-Classes which I serialize and send via TCP.

I start realizing that creating a seperate Message Class for each possibile communication scenario is quite an overhead and consider moving to WCF.

Therefore I need to know the following things:

1. It seems that the whole communication using WCF is based on the clients callind exposed methods from my WCF service. Is there a way of knowing which client calls a certain method? This is quite important for my application.

2. Does WCF notify my application, when a client disconnects (eg closes the browser window where the Silverlight client is running) from the server? This too is quite important.

3. Are the method calls completely asynchronous? If so, do I have to reroute each method call to the main thread of the server application?

4. Does every client connection has its own thread? How many simultaneous connections could the server (running on a reasonably powered PC) handle if the clients call methods say every 2 seconds? I just need a estimation (10, 100, 1000 or even more). "More" would be great ;)

Maybe I am completely wrong and WCF doesn't work connection-based at all. Then I would have to find a workaround to still manage a list of active connections.

Thanks for your help! Andrej

Answer 1

1. Since you are using a Silverlight application, you can implement a UserNamePassword Validator on the message layer, which adds some headers to the soap message, this could be used to uniquely identify clients, unless clients are anonymous. then you can use System.ServiceModel.OperationContext.Current, when you need to access the username elsewhere in the wcf service.

2. The server is not notified when the client disconnets, since msgs are "PerCall" by default, there is a way, use a Singleton class as ur ServiceContract with InstanceContextMode.Single, then implement an OperationContract with a callback service, then when clients login to ur service they must register with the callback service, ur callback service can then cycle through connected clients and check the status of the callback, whether its still open or not, finally remove entries where the connections are closed, eventually you can get the functionality you require.

3. Async calls, are from the client, ie. in Silverlight all webservice calls are async, like in ASP you have a choice, WCF handles the async functionality automatically, so you dont need to reroute anything, just code the ServiceContract like its a single thread, and everything will be fine

4. Implement binary message encoding in silverlight 3, to get the most out of ur server and its bandwidth, silverlight does not support raw tcp connections, it has to be rapped in an http message for very good reasons. Each client can have many concurrent calls (async remember), so to keep things simple, just think of it as if the server assigns a separate thread to every message call. So to answer your question on what you just said, 1000.

Answer 2

For 3 i know You can call async.

And for 4 yes, they have their own threads. WCF is pretty "BIG" and complex, you should get a book to understand it better.

Answer 3

My answers:

1. Yes. All communication is based on calling methods.
2. In general - No.
3. You can call methods synchronously or asynchronously. This is you choice.
4. More. I case of right system design.