tags:

views:

28

answers:

1

First of all, this is a follow-up question to http://stackoverflow.com/questions/3325847/should-i-use-wcf-or-raw-sockets. Thanks to everyone who responded, it helped me a lot!

Lately, a few of my requirements changed. The main hurdle that came up is that I now have to support Linux clients in addition to Windows. I have to use .NET at server side as a requirement. I also need to maintain persistent connections with clients (or poll). I would like to request feedback from the community on the following options:

  1. Use a simpler version of pub-sub model. I have a web service at the server which the clients constantly poll (I prepackage the scripts/binaries that I need to run at the client and issue commands from the server via the service). The server puts the tasks for clients in a queue, and the clients pick it up. This model becomes highly interoperable, as I can write the client in any platform. Also, I don't have to worry about firewalls at client side because of http. However, I am concerned about the polling (I might have to poll every few seconds, for 1000s of clients). I read about Comet, but unfortunately, it seems like a lot of effort to implement it in C#.

  2. Use normal sockets, create a persistent connection from clients and use those pipes. Here, I'm concerned about persistent connections (I need them to control the client, they are behind NATs). Normally, I've seen people creating a thread for each connection, which I believe is not scalable. Am I correct? Is asynchronous calls/socket selects a better way to go?

Any comments would be greatly appreciated.

A: 

Using standard sockets to communicate will be portable among different OSs. Plain tcp sockets are a very mature technology. You could also use web services (http), those sit on top of sockets. Web services are more practical when going across the internet (firewall issues etc).

seand
Thanks seand, I decided to go with plain TCP sockets!
Andy