Server side for a multiplayer turn based silverlight game.

Question

I am currently in the early stages of designing a browser based game using silverlight. The game is going to have many matches of 2-4 players (perhaps even up to 8) and will be turn based.

The Front end is Silverlight 3.0 since I have some experience there. I am trying to figure out what the back end should be. Since the game is turn based it will not need to poll the server as often as a real time game. The server end will include some sort of intermediary layer which communicates between the client and the back end. The back end is going to be a c# based Windows service which performs validation and calculations based on user actions (attack, defend, move, skills, leveling etc etc).

What are the pro's and cons of the following for middle communication layer between the Silverlight 3.0 Client and the c# windows service on the server.

1. Sockets
2. WCF / WCF Duplex Service
3. .Net RIA Services

Currently I don't know anything about the three options above, however I have in the past created ASP.Net Web services and in university I did some socket programing that I have mostly forgotten.

Answer 1

Here is my view of things:

Sockets: Upside is that this can perform really good. Downside is that it is somewhat fragile and complicated to implement both on the client and on the server. I would avoid this unless there is no other way (e.g. you need very high performance).

WCF / WCF Duplex: WCF is very easy to implement if you just take ten minutes to think about what you want to send back and forth. Performance is good and deployment is easy. This would be my first choice for an online game.

WCF Duplex is somewhat more complex. There are some good tutorials as to how to get this to work, but I find there are some pitfalls that may not make this worth the effort. If you don't need high polling intervals I would stick with normal WCF. As far as I know WCF Duplex does polling as well so it's not really duplex.

.NET RIA Service: I'm not sure about this one, but I figure the overhead is not what you need when having large volumes of traffic. Also from forum questions I learn that this one is not so easy to customize, whereas WCF is more flexible.

Conclusion: Unless there is some compelling reason not to, I would stick to WCF.