WCF Scalability with Session

Question

we are evaluating a new project which will have a .NET Server which is available in the internet. We have access to the server but the hosting is done by a 3rd party company.

We are evaluating using WCF on the .NET Server. (I have no professional experience with WCF and just reading into the topic). The WCF service will talk to a SQL Server to perform its duties.

Here is the scenario:

Multiple client machines running our own ActionScript software will connect to that .NET Server.

• Clients might be online 24/7 and should periodically poll our server to tell the server that they are there.
• A client needs to be able to login, and only if the login has worked the other calls will be allowed and at some point it logs out. So we need to "remember" the state with a particual client...
• Highest expected load is around 1000 Clients, of which 500 will only do polling while the other 500 will be "active". "Active" means a maximum of 1 call each minute, no heavy payload in each call, neither in the request nor in the response, just 1-3 database accesses per call.

We already tested some "HelloWorld" with ActionScript and WCF using BasicHttp(s)Binding. But because we need session handling we were thinking about taking using the wsHttpBinding binding because it can provide us WCF Sessions. So far so good, but then I stumbled upon the fact that it should However:

I find that in my Oreilly WCF Services 3rd edition book (Page 177) it is written

and even Microsoft is writing to be careful using that:

http://msdn.microsoft.com/en-us/magazine/cc163590.aspx

"A service configured for private sessions cannot typically support more than a few dozen (or perhaps up to a few hundred) outstanding clients due to the cost associated with each such dedicated service instance."

So because we need to identify the state with each client, we could of course implement our own "Session Handling" on top of stateless HttpBindingBinding, and make a call to that SessionHandling class each time when my WCF methods get called, but I am reluctant to do anything like that, it looks to me like thousands of people should already have faced the same problem.

So, my question now is: Do you think wsHttpBinding on my server could handle the payload? How "bad" is it really to go with wsHttpBinding on WCF? Does anybody already have experience with this? Can I use it? What would you use?

Final Remarks: I am not limited to WCF if we dont like it, we just shall do an evaluation.

From the companies point of view it would also be fine to go for a protobuf-RPC or XML-RPC solution over TCP and the ActionScript clients implementing that. (just examples!) So no need for hosting WCF in IIS on the server as long as the coding part is comfortable (enough) for the programmers on both sides and the ADMINISTRATION on the deployed server is not too much either. With just making some TCP-ports based communication I am a bit afraid what it would mean for the administration in regards to firewall and stuff. Payload is not an issue, client processing power is also not an issue. The only thing I am concerned about is scalability of the server and security.

Thanks in advance for any suggestions!

Answer 1

I would not be concerned with scalability. You can always add a server or two to your farm in case of issues.

I would rather be concerned with your architecture and the need to store anything in session - are you sure about that?

Note that you don't need ws binding to support sessions, basic binding supports sessions as well.