Asynchronous Communication Between Two Applications

Question

I'm writing a simple little game for my kids - it doesn't really matter what it does, though I couldn't tell you anyway, since I/they haven't quite decided yet! However, I think it will have a server component and a number of client components, and I'm looking at ways that the clients can communicate with the server.

ALL my previous experience... my entire career in fact... has involved the server element either being a database, a web server, or the two in tandem. Neither are appropriate in this case, so I'm curious as to what means I could & should use to communicate between the two.

Obviously, it would be preferable to adopt a technology or technique that I can re-use in my work, where I'm increasingly working with Windows Forms. I imagine there are 1001 different approaches I could adopt; it's a question of sorting the wheat from the chaff.

I've literally just started reading about WCF, but its unclear as yet, if this service-oriented approach is what I'm looking for.

I'm being deliberately vague about what the applications will do; I expect the client will announce their presence to the server, will feed user choices up to the server, and in return, the server will periodically update the client with what is going on in the wider game. The game will be turn-based rather than real-time... and quite low-tech really!

Suggestions? Ideally, with links to good learning resources if any are known.

Conclusion: I actually thought there might be more viable alternatives; there is Remoting (now depracated), but the consensus says that WCF is the way to go - in my case, self-hosting looks appealing.

Thanks for the responses.

Answer 1

I would look at Remoting if I was you. It is fairly easy to impliment and you can definatly use it at work.

There is a tutorial on it here: http://generally.wordpress.com/2007/05/31/a-simple-remoting-example-in-c/

Answer 2

It looks like you're interested in WCF and that is a reasonable technology to use in this case.

When writing a network game the easiest approach is to use the client server approach here too. With WCF you have some different hosting possibilities, hosting in IIS or self hosting. I would go for self hosting to avoid the need for IIS on your home computers.

The service could be hosted in either a windows service or actually in one of the clients. I recommend running as a windows service. The service could very well run on one the same machine as one of the clients.

Edit:
If you want to host the server in one of the clients you could provide a menu option "start service" that starts a self hosted service on that computer (and automatically connect the client part to localhost). After the service has started you can present the computer name that you enter on the "other" computers to connect.

I would suggest to separate the service part into a separate project, then you can easily break out the service to a windows service later on if you like.

Edit2:
By the way, since WCF is driven by calls from the client you need to poll the server for changes. You can google wcf long polling or just long polling for methods to "push" messages from the server to the client.

Answer 3

Here is a good book on WCF, which can help get you started. It has quite a bit of a learning curve (I still have barely scratched the surface myself), but I get the sense that it's a very powerful way to set up a service-based application. On the page I linked, check out the Examples link, which includes a bunch of code from the book, including Juval's ServiceModelEx, which has a wide variety of useful classes for working with WCF.

Answer 4

Check out this article on creating a chat application using WCF -- http://www.codeproject.com/KB/IP/WCFWPFChatRoot.aspx

I've played around with this code in the past and the project was pretty simple to launch locally.

Answer 5

I'm going to go against the crowd here and suggestion NOT using WCF. WCF is a great technology for service oriented architecture, however it is largely written on the idea that clients will not stay connected to the server, but rather connect, send a message, perhaps receive a result, and disconnect.

There is a mechanism that can be used for long connected clients, but frankly, it doesn't work very well, has all kinds of issues and quirks, and is not very reliable in terms of knowing when clients have disconnected or not, or whether the clients know if they are still connected to the server. It's more of a bolted on solution that tries to shoehorn itself into the WCF model.

The other issue is one of firewalls. There can't be a firewall between the initiator and the receiver (or there must be an open port). That means you can't easily have two clients behind firewalls that want to talk to each other. You need some kind of exposed intermediate server that is open. While this problem applies to all solutions, it's easier to manage with straight TCP connections than WCF.

I'm not a huge proponent of rolling your own solution, but WCF really is overkill for simple two way communication between client apps.

I have not yet found a good open source network library for .NET. I know lots of people will chime in with various libraries, but every one i've seen is old and has various flaws. Most seem to be someone that ripped out their library from an app and tried to package it as a generic one, but leaving in all the assumptions of their app.

The problem is that recent versions of .NET have added lots of new network functionality, particularly in terms of asynchronous support. As of yet, i've not seen any libraries which implement these functions.

Anyone want to help me build a good, from scratch, network library based on .net 3.5+?

Answer 6

Hi CJM, you also can consider to use the communication via messages by using Eneter Messaging Framework. The framework is really light-weight, easy to use and supports various communication scenarios (one-way communication, request-response, publish-subscribe, ...). It can communicate via Named Pipes, Tcp or Http and also it can be used for the communication between threads.

If you are interested you can check link text.