Better approach for having two or more threads listening on same port

Question

Dears,

I'm currently working on a network server application. I plan to have one thread for each server's core handling clients connections in order to do a better use of server's resources and get faster responses, avoid blocking, etc.

From what I know, there are two ways of doing it:

1) parent process opens listening socket and each thread monitors it (epoll, kqueue, etc.) for new connections and accept() them;

2) each thread opens its own listener socket on same port and address (possible thanks to SO_REUSEPORT and SO_REUSEADDR), monitor it for new connections and accept() them.

I'm not sure about how it works behind the scenes, but I suppose doing it like #2 will delegate to kernel networking section the task of distributing client connections over threads. Is it correct?

Is there any significant difference between two approaches? Is there something that can go wrong in a way of doing it whereas it doesn't happens in other? Will I get better results (less resources usage, less latency, etc.) doing it in some specific way instead of another?

I think only way to see some difference between two approaches by comparison is generating a huge amount of connections, but my poor computer can't deal with it. So I fall back on your experience and knowledge to get an answer for this question. Thanks in advance for your help.

Answer 1

Here a suggestion , When parent thread started to listen for the request then new thread only created when new connection arrived and return a new socket for that request , now you can use that socket in any thread as you like , there will be no problem . Thank .

Answer 2

1) parent process opens listening socket and each thread monitors it (epoll, kqueue, etc.) for new connections and accept() them;

You can do that, but there's not a lot of benefit over having a single accept() thread and a thread pool. And you will have races between the accepting threads that only one of them will win at a time (the 'thundering herd' problem).

2) each thread opens its own listener socket on same port and address (possible thanks to SO_REUSEPORT and SO_REUSEADDR), monitor it for new connections and accept() them.

You can't do this with TCP unless you are on Windows, where the semantics as far as I can tell are undefined.