Multiple threads for multiple ports?

Question

Hello, To start off, I don't know very much about network programming...

So given that, I have a program (process) which needs to listen on 3 ports... Two are TCP and the other UDP.

The two TCP ports are going to be receiving large amounts of data every so often (could be as little as every 5 minutes or as often as every 20 seconds). The third (UDP) port is receiving constant data. Now, does it make sense to have these listening on different threads?

For instance, when I receive a large amount of data from one of the TCP ports, I don't want my UDP stream interrupted... are these common concerns for network programming?

Thanks guys... feel free to ask clarification questions if I'm not being clear.

I'll be using the Boost library on Windows if that has any bearing.

EDIT: After reading this again, I realized I'm not asking a specific question lol... I guess I'm just looking for some thoughts/ideas/guidance on this issue and how to manage multiple connections. Thanks

Answer 1

Using threads, one per receiving connection, will help keep the throughput high and prevent one port's data from blocking the processing of another ports.

This is a good idea, especially since you're talking about only having 3 connections. Spawning three threads to handle the communication will make your application much easier to maintain and keep performant.

Answer 2

First,

...are these common concerns for network programming?

Yes, threading issues are very common concerns in network programming.

Second, your design idea of using three threads for listening on three different ports would work, allowing you to listen on all three ports simultaneously. As pointed out in the comments, this isn't the only way to do it.

Last, one design that's common in network programming is to have one thread listen for a connection, then spawn a new helper thread to handle processing the connection. The original listener thread just passes the socket connection off to the helper, then goes right back to listening for new connections.

Answer 3

In general, avoid threads unless necessary. On a modern machine you will get better performance by using a single thread and using I/O readiness/completion features. On Windows this is IO Completion Ports, on Mac OS X and FreeBSD: kqueue(2), on Solaris: Event ports, on Linux epoll, on VMS QIO. Etc.

In boost, this is abstracted by boost::asio.

The place where threads would be useful is where you must do significant processing or perform a blocking operating system call that would add unacceptable latency to the rest of the networking processing.

Answer 4

Multiple threads do not scale. Operating system threads are far too heavy weight at the scale of thousands or tens of thousands of connections. Granted, you only have 3, so it's no big deal. In fact, I might even recommend it in your case in the name of simplicity if you are certain your application will not need to scale.

But at scale, you'd want to use select()/poll()/epoll()/libevent/etc. On modern Linux systems, epoll() is by far the most robust and is blazingly fast. One thread polls for socket readiness on all sockets simultaneously, and then sockets that signal as ready are either handled immediately by the single thread, or more often than not handed off to a thread pool. The thread pool has a limited number of threads (usually some ratio of the number of compute cores available on the local machine), wherein a free thread is grabbed whenever a socket is ready.

Again, you can use a thread per connection, but if you're interested in learning the proper way to build scalable network systems, don't. Building a select()/poll() style server is a fantastic learning experience.

For reference, see the C10K problem:

http://www.kegel.com/c10k.html