Design considerations for a multiplayer card game

I've been working on a card game engine in C# .NET for some time now. It is nearing completion at this point, but the interface so far has just been a simple console one with ReadLine and WriteLine.

For data, I have a GameState object that stores pretty much all of the relevant information to the game at a given point in time. The rest of the game is heavily event-driven.

I'm looking to branch this out into a full-blown online application. I've been reading a lot about WCF and its callback support in web services, and this seems like a decent option for me. However, I'm open to other ideas if one fits well.

The only problem I'm anticipating is a threading nightmare when I try to do this. I have an approach I am thinking of that might reduce threading woes as much as possible:

1) Have the WCF service only ever request data from the user (e.g. prompt for some action) through the callback interface AND supply several one-way callbacks to notify the client about updates to the game state. Emphasis: clients can not 'query' for game state. The only way for them to send data to the server is if the server asks for it through a callback.

My only worry is that a client might need to request for some data from the server in some way I am not anticipating. If the situation arises, I could provide some ways for the client to read the game state, but now I have to start thinking about Reader locks on the GameState object.

I suppose that if I have to, I will dig in and try t开发者_开发百科o make this thing thread safe, but I wanted to run this by you guys to see if you have any suggestions.

---

If you want this to be a web application (html) then I would say your best bet would be to use web sockets (natively supported in chrome, flash plugin for other browsers) and integrate a websocket-server like nugget into your code. This enables real push communications from server to clients.

If you are creating a silverlight frontend you have many options but from what I've gathered the only real option if you want to scale past 500 online clients at once is to use a custom server as IIS can't handle very many clients at the same time. I chatted with the guy making a silverlight version of Agricola and he used a custom server which integrated nicely with iis called websync which is quite pricey for a hobbyist, but seems awesome.

If you are creating a rich client you are free to throw anything at it, even using binary socket communication natively with WCF.