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

Hi
I agree Sockets are very low level - but from your problem description, it looks like you want the server to initiate communication with the clients in addition to the usual client -> server communication (i.e. client initiated). I am also new to WCF and I know WCF supports Duplex communication. But my GUESS is that when a client makes a request it also passes along a callback function which the server can call upon. So the model is still client -> server followed by server calling the callback.

Server initiated communication with WCF is something I am not aware of. So you may want to check this before you decide on either of the two.
You also could consider a combination of both, as in, WCF for most scenarios and a separate thread handling Socket Communication for those cases where WCF is not suitable/possible.

Thanks
VM

Answer 3

You can use WCF. It allows you to do callbacks to client. start here: http://idunno.org/archive/2008/05/29/wcf-callbacks-a-beginners-guide.aspx

And I also agree with another answer: it is much more productive to spend few days on WCF evaluation instead of going to sockets. In future you will need to get a lot of features absent in socket.. so you will need to implement them yourself. While WCF provide them out-of-the-box.