Should I use WCF or raw sockets?

Question

I wish to develop a client-server application in .NET that functions as follows:

1. Clients connect to a central server. The server needs to keep track of which clients are connecting, and it must allow only those it knows (I have a repository of allowed clients). This is because in my application, it's critical to know who all are present at a given instance.
2. The clients could be connected to some other devices, say over LAN/USB/Serial ports. The server should be able to control these connected devices through the client. For example, let's assume the client is connected to a camera. The server should be able to switch on the camera at some particular time, and then get back the images (or make the client do it and upload the result to the server).
3. I would also like the ability make these clients run custom executable and get the result. For instance, the server sends an application to (or invokes some existing ones in) the client, makes the client run it, and gets back the resulting data.

I'm just wondering if I can use WCF for this purpose, or should I go with good old sockets. Although the initial network would be small, I want it to scale (1000s of clients). Any suggestion would be greatly appreciated.

Answer 1

Today I would never go down to such a low level as sockets unless you really have to. Working with high level abstractions is way more productive and creative. Better spend 2-3 days of learning WCF or .Net Remoting then 2 weeks of debugging low level socket stuff.

We had a similiar decision to do a few weeks ago. We decided to use Remoting, since you can work on object level, its damn simple to set up and quite efficient. We could have used WCF, but it was not that simple to set up.

The big advantage of Remoting or WCF is that you can pass objects between server and client and call methods on them on each side.

Suppose you have written an abstraction for your camera like:

class Camera
{
    public CompressedImage GetFrame()
    {
        ....
        return image;
    }
}    

Then you can create a remote object on the server and write something like:

var cam = SomeClientObject.GetCamera(); //get proxy object for the cam
....
var frame = cam.GetFrame();

which will call the method GetFrame() on the client and pass you the image over the (inter-) net, if the image is serializable. The only thing you have to keep in mind is, which objects create a proxy on the other side, and which objects are copied to the other side.

Thats really powerful and woks for us like a charm. So free your mind from sockets :)

Answer 2

I've just been doing the exact same thing. I wrote a TCP-based server that can handle 1,000 simultaneous client connections with ease in about an hour and culminating in 80 lines of code. I have spent days trying and failing to get a duplex WCF server to do the same thing. It took 175 lines of code to get a duplex WCF server and client working at all and it crashes if 30 clients try to connect simultaneously.

So I must disagree with the other answers here: I have found WCF to be an absolute disaster and raw sockets to be much easier and more reliable.