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 Messa
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.
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.
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
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.