kurifu

I am working on a project which uses a client/server model. The client will connect with the server using a TCP/IP connection (though I have considered using UDP/IP).

For server design though there are two ways I have figured I can go with the design assuming that I stick with TCP/IP sockets:

Threaded Blocking Sockets:

One main thread watches for incoming connections and managed a pool of threads. When an incoming connection is heard, one of the threads is signalled to take over to complete the connection and authenticate the client.

Pros are that the model is fairly simple, it is easy to manage individual sessions. And any work that needs to be done can be placed into a Producer/Consumer Queue for processing. Also this would mean little latency on the connections.

The cons are that it consumes a large number of resources, and I am not really sure what the maximum number of threads I can expect the service to load, the C# thread pool object (which I am not using) has a default maximum of 25, which really is not much.

Additionally if I place work in the processing queue I have to wait for work to be complete, which means no more socket activity until something is returned, or the sockets now have to become non-blocking so that I can also simultaneously check for work results.

Non-blocking Server Approach:

With a TCP/IP system this would mean establishing a connection and placing it into some sort of list, traversing the list polling each of the sockets for data. When data is received, place the work in the queue and check this after polling all sockets for work results, sending data back on the appropriate sockets when complete.

This uses many less threads, however poses a problem with latency. Latency probably isn't a large concern, but I still want to keep it at a minimum. After so many connections I would have to spawn other threads to monitor data, so I don't overload the polling process.

UDP would take a similar approach, only it would not be necessary to keep a list of active connections, for obvious reasons.

Anyone have any insight on which approach would be the best?

__________________
Clifford Matthew Roche <geek@cliffordroche.com>
Web Hosting: http://www.crd-hosting.com
Consulting: http://www.crdev-consulting.com

Infinite Recursion

It would really depend on the load of the transactions and what level of system resources you have available.

Threaded Blocking Sockets would be your best bet if you are looking to process transactions quickly. If you are expecting >25 connections then hopefully you have a way around the thread pool object limitation. I'm thinking the resource consumption would be limited and would fluctuate within acceptable ranges (based on current hardware) in relation to the rise and fall of the transaction load.

If the resource consumption became a problem and you would be willing to take a slight hit in speed, you could go with the Non-blocking Server Approach and try to allocate resources on-demand.

__________________
http://jasonpowers.net

"There are a thousand hacking at the branches of evil to one who is striking at the root."

lectricpharaoh

Why do you need to use polling if you're using non-blocking sockets? By passing a unique object to BeginReceive(), such as the receiving socket or your own user-defined type (representing a connected client, for example), you have a mechanism for determining which object has the read completed when your callback is invoked. Depending on what you want to do, you can handle it in the callback method, or you can raise an event for your program to handle.

If you do raise an event for handling, though, be careful not to overwrite the just-received data in the buffer when making a new call to BeginReceive() in your callback. Either put the bytes into a new portion of the buffer (you can use it like a circular buffer in this regard), or allocate a new buffer (less efficient and perhaps needlessly complex, as you need to store a reference to this buffer for each read operation).

__________________
And once again, Probability proves itself willing to sneak into a back alley and service Drama as would a copper-piece harlot.
- Vaarsuvius, Order of the Stick

kurifu

If you are using BeginReceive, then you are using asynchronous sockets. I prefer to stick with synchronous sockets.

__________________
Clifford Matthew Roche <geek@cliffordroche.com>
Web Hosting: http://www.crd-hosting.com
Consulting: http://www.crdev-consulting.com

kurifu

IR: in retrospect, I will have very few working threads as most client server connectivity will be very minor "check for updates" kind of events. However a couple of clients will be sending large amounts of binary data.

I think you are right, a low latency setup will be best here for me, and I shouldn't need to spawn too many threads to get this done.

The default threadpool object isn't powerfull enough for me to use outside of the Producer/Consumer queue, so I will have my own ThreadPool object, but in both circumstances you can change the max number of threads from 25 to whatever limit your hardware will allow.

__________________
Clifford Matthew Roche <geek@cliffordroche.com>
Web Hosting: http://www.crd-hosting.com
Consulting: http://www.crdev-consulting.com

Dameon

"Check for updates" hmmm? Why not download a text file containing the latest version number and link from a web server. That's just a few lines.

__________________
MD5(sig) = bcef75433db02e9ad9bf81d6f7c5c270