I am planning to code a tcp/udp server. The program is required to accept tcp and udp connections so I need both protocols running on the server.

I have 3 plans on how I would build the server and I am not sure which one would be better.

Plan 1: The program would open both tcp and udp sockets and then use select() on both.

Plan 2: The program would create 2 threads. one thread is for the TCP and the second one is for the UDP. I would still use select().

Plan 3: Make the program check for an argument that would signal the program to either start as udp or tcp server. So this would mean two instance of this program would be running one would be listening on tcp and the other on udp.


Which would be better? I would be using select() to check if I data is available.

Ok, now that the thread hijack is over, let's return to:
There might be factors of which I'm unaware in your situation, but just with what I know of your question, I vote for 3, then 1, then 2.

1 is superior to 2 because at any given time you're responding to one event, so you don't need to worry about synchronizing access to data.

But assuming that the TCP server and the UDP server don't share any data, 3 is superior to 1, because you don't have two otherwise independent chunks of code sharing the same heap. This makes the code easier to debug in case of buffer overrun. Otherwise, for example, the UDP server code might trash the heap but still be smiling with glistening teeth as the TCP server code dies because of the heap corruption.

deleted

So, to summarize your question, you want to know whether it is better to use a single thread, or to use multi-threading or to use multi-processing (although you didn't suggest the fourth possibility, which is to fork() a new process within your single application). To answer this question is only possible when we know the overall makeup of your application. If there was always one best method, then everyone would always use it, and the others would probably not exist.
If the handlers for the two servers have much overlap (shared data or code), then single-threading or multi-threading is probably best. Since you've considered the possibility of multi-processing, I'll surmise that the two servers have little or no coupling, so a multi-processing approach may well be your best bet.

--- rod.

I decided to go with multi-processing since they don't share data. I also think it is much safer that way because of wje_lq's post.