Non-blocking Socket Polling vs Blocking socket

Question

I need to send and recv at the same time.
Which option would be better:

1 thread handling send & recv with non-blocking socket

or

2 threads with one handling blocking recv() + one handling send()?

Or is there another solution?

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

score 4 · Answer 1 · edited May 23 '17 at 12:31

4

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.

edited May 23 '17 at 12:31

Community

1
1

answered Jun 04 '09 at 13:17

Pablo Santa Cruz

176,835
32
241
292

+1 Although this question isn't a Java question, it lends itself really, really well to using Executors in Java, which implements pretty much the model you've described in your linked post. – C. K. Young Jun 04 '09 at 13:18
Yes. Executors are great. Definitely. – Pablo Santa Cruz Jun 04 '09 at 13:22

score 3 · Answer 2 · answered Jun 04 '09 at 13:15

3

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

answered Jun 04 '09 at 13:15

C. K. Young

219,335
46
382
435

is poll a standard C/C++ function? Can't seem to find it.. Thanks – Jun 04 '09 at 13:46
It's apparently an "X/Open System Interfaces Extension": http://www.opengroup.org/onlinepubs/009695399/functions/poll.html – C. K. Young Jun 04 '09 at 21:20
In that sense, select is probably "more standard": http://www.opengroup.org/onlinepubs/009695399/functions/select.html (However, I still support using poll, for platforms that support it.) – C. K. Young Jun 04 '09 at 21:24

score 0 · Answer 3 · answered Jun 04 '09 at 13:14

0

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.

answered Jun 04 '09 at 13:14

mmmmmmmm

15,269
2
30
55

poll, not select! :-P (Okay, if you're using WinSock, select is probably more portable, but you can also use WSAWaitForMultipleEvents in that case, which is like poll. :-P) – C. K. Young Jun 04 '09 at 13:16
1

It was an answer to the "Or is there another option?" part of his question. And since he didn't mentioned any platform I had chosen the most portable version which is select() [Available in C/C++, on Windows/Linux, PERL and many, many other languages!) – mmmmmmmm Jun 04 '09 at 13:34

score 0 · Answer 4 · edited May 23 '17 at 12:08

If you are concerned about performance and scalability, try IOCP (async socket read/write): How to write a scalable Tcp/Ip based server

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.

Non-blocking Socket Polling vs Blocking socket

4 Answers4