Non-blocking Socket Polling vs Blocking socket

Question

I need to Send & Recv at the same time, which should be the best:

1 thread handling send & recv with non-blocking socket or 2 threads with One handling blocking recv() + one handling send()

Or is there another option?

I am expecting to have up to about 50 2 way connections.. Which result in 50 thread in option1, and 100 thread in option 2.

Thanks

Answer 1

You could use one thread with two non-blocking sockets and use select() to wait for incoming input and space in output queue.

Then you do not need to poll because select() blocks without using processor time.

Answer 2

You should use non-blocking sockets, but rather than polling them manually, you should have the kernel do it for you. Use either poll or select for this (the former is preferred, because it can handle more sockets at once). When you do this, you will end up with 1 thread in option 1, or 2 threads in option 2. :-P

Answer 3

I wouldn't use either of those approaches.

Take a look at this SO question. I would use a worker threads model where you would have N thread handling all traffic with non-blocking sockets.

If you absolutely HAVE to follow one of the approaches you've just described, go with non-blocking IMHO.

Answer 4

If you are concerned about performance and scalability, try IOCP (async socket read/write): http://stackoverflow.com/questions/869744/how-to-write-a-scalable-tcp-ip-based-server/908766#908766

Note that it is a lot trickier to implement IOCP than 'a thread per connection', and since you are only going to have 50 connections (or 100 threads as you suggest), that may be 'good enough' and simpler to implement correctly.

Try the simple approach and measure it... but if you either: need more performance, or, are going to scale (far?) beyond 50 connections, seriously consider IOCP as a better solution.