What to use? WCF or Sockets? in a C# program

Question

I am in the need of creating a C# program that will run on couple of our local Windows client machines. These 'client' programs will have to take commands from a 'admin' program run on another machine. The commands could be to reboot the client computers, return some local information about IP address etc back to the 'admin' program.

But how to accomplish this? I know a little about WCF but is that the right way to go? If I go with WCF I will then have to make the client programs run a service method, like every second, to check for new commands. With sockets I establish a 'direct' connection and the client just waits for a command to receive - isn't that correct understood?

Which way would be the right way for me to go?

We are talking about ~10 clients and I want a maximum delay (send command - receive info back) of 1 second.

Any hints would also be appreciated.

Best regards

Answer 1

With the small number of machines and modest performance requirements you mentioned, I think WCF would end up being easier than sockets.

You might look into Duplex WCF. I've never used it, and WCF has given me headaches in the past any time I've needed anything unusual, but it's for the sort of problem you're talking about.

If all the machines are on one network, here's one creative alternative loosely inspired by message queues: you could use a database table as a place where messages appear and get read by clients at their leisure. The clients could just query it and say: get me all messages where MessageID > LastReceivedMessageID.

The downsides of that last approach is that (a) you're still doing polling although your database server should be able to handle it and (b) if you might ever need this outside of your network, you would need a VPN or a new solution.

Answer 2

I would recommend a socket implementation as in the long run it probably gives you greater flexibility. You could create this from scratch yourself using the socket namespace. As an alternative you could use an off the shelf network library solution. Checkout lidgren and NetworkComms.Net.

Disclaimer: I'm a developer for NetworkComms.Net.

Answer 3

Duplex WCF server. Basically, the clients all connect into the server (so only 1 server), and the server uses its duplex channel to call back to the clients whenever it needs to. No polling, scales well, etc. The most headache you'll need to deal with is to set a long timeout in case that you don't send anything for a while so that the channels time out.

WCF will end up being much simpler in the end.

A couple of links:

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

and

http://www.codeproject.com/Articles/491844/A-Beginners-Guide-to-Duplex-WCF

I hope those help.

Answer 4

you could use MSMQ... couldn't be easier to implement

http://msdn.microsoft.com/en-us/library/windows/desktop/ms711472(v=vs.85).aspx

I use MSMQ for a number of similar applications. Works perfectly.

Answer 5

You could use .NET Remoting which can provide a "push" backchannel from the server to the client (using "callbacks"). It does not need a 2nd TCP connection in the other direction so you don't need to mess with client's firewalls and routers.

Remoting is considered kind of obsolete but it has its places.

In any case I would not use a WCF polling technique. That leads to bad latency and a DDOS situation for the server.

If you can make the clients open a port then hosting a WCF service there is probably the best idea.

Answer 6

You can make WCF clients act as servers and with command & control program connect to them that is no problem. Go for WCF if you don't want to mess with ugly stuff that sockets can bring. WCF can be configured nicely in app.config, and you can make it really self hosted command line application even so no need for IIS server. Configuration will be then resuable and easier to maintain.