What is the best way to handle a C# server?

Question

I'll have about 10 computers communicating with the server on a regular basis.

The packets won't be too data intensive. (updates on game data) The server will be writing to a postgres database

My main concern is concurrent access by the clients. How can I handle the queing in of client requests?

• Is WCF a good route? So for instance, rather then opening tcp/ip streams is it feasible to use GET/POST requests & such by WCF over a LAN?

Can anyone suggest any other areas of focus for possible problems?

Answer 1

With WCF you have so much flexibility choosing what to use depends on what to you want to do. Knowing what to choose comes from experimentation and experience.

You can use tools like Fiddler, Wireshark and ServiceTraceViewer to analyze the conversations between clients and the server - they should be used periodically to detect inefficient conversations.

You're producing a game that needs to communicate data via a central server...thus presumably you want that to be as efficient as possible and with the lowest latency.

Thus ideally any requests that come into the server you want to be processed as fast as possible...you want to minimize any overhead.

Do you need to guarantee that the message was received by the server and consequently you are guaranteed to receive a reply (ie reliable delivery)?

Do the messages need to be processed in the same order they were sent ?

Then consider does your server need to scale? will you only ever have small number of clients at a time ? You mention 10?.....will this ever increase to a million?

Then consider your environment....you mention a LAN...will clients always be on the same LAN...ie Intranet? If so then they can communicate directly with the server using TCP sockets....without going through an IIS stack.

With certain assumptions above with WCF you could choose Endpoints that uses a netTCPBinding with Binary encoding, and with the Service using:

[ServiceBehavior(InstanceContextMode = InstanceContextMode.PerSession)]
[ServiceBehavior(ConcurrencyMode = ConcurrencyMode.Single)].

This would establish sessions (as long as you use a Binding that supports sessions) between the clients and server (doesn't scale because each client gets their own server instance to manage their session), it would allow multiple clients to be handled in parallel, and the Binary encoding "might" reduce data size (you could choose to avoid that as you said your data isn't intensive, and Binary might actually add more overhead to small messages sizes).

If on the other-hand your service needs the ability to infinitely scale and keep response times low, doesn't mind if messages are lost, or delivered in a different order, or have to be deliverable over HTTP, etc, etc, then...then there are other Bindings, InstanceContextModes, message encodings, etc, that you can use. And if you really want to get sophisticated, you can get your Service to expose multiple Endpoints that are configured in different ways, and your client might prefer a particular recipe.

NOTE: (if you host the WCF Service using IIS and you are using netTCPBinding then you have to enable the net.tcp protocol....not needed if you self-host the WCF Service).

http://blogs.msdn.com/b/santhoshonline/archive/2010/07/01/howto-nettcpbinding-on-iis-and-things-to-remember.aspx

So that is "1" way to do it with WCF for a particular scenario.

Experiment with one way...look at its memory use, latency, resilience, etc. and if your needs change, then change the Binding/Encoding that you use...that's the beauty and nightmare of WCF.

If your clients must use HTTP and POST/GET requests then use a Http flavoured binding. If you need guaranteed message delivery, then you need a reliable session.

If your Service needs to infinitely scale then you might start looking at hosting your Service in the Cloud eg with Windows Azure.

http://blog.shutupandcode.net/?p=1085

http://msdn.microsoft.com/en-us/library/ms731092.aspx

http://kennyw.com/work/indigo/178