Handling of multiple UDP streams

Question

Let's assume I have m UDP streams uniquely identified by some id (eg RTP SSRC). I need to process them in n associated threads and association is 1-N , ie one UDP stream is processed by one or many threads.

What is the difference in kernel's networking stack performance if I:

1. Start m UDP servers each on different port. Each server processes one stream and pushes it's data to one or more associated threads.

2. Start just one server. All streams are handled by it's single port and this thread pushes each stream data next to one or more associated threads.

I think it comes down to the question: is it better to open one single port or many of them, where each will receive proportionally less data?

Is there possibility that single socket may be overwhelmed by the amount of incoming data? Or maybe socket, which is more logical thing in linux kernel than a physical thing, has not so much to do that the data itself, so there is no real difference?

What is the maximum bitrate the single UDP socket (with enlarged buffer) can handle?

I am sure I will best find the answer by browsing of kernel's networking code but maybe someone could give the answer straight away please. Thank you.

Answer 1

There is no easy answering this question because it all boils down to the processing speed of your threads and how you delegate the work among them.
If you think that the udp socket is going to be overwhelmed you can create a queue right behind the udp socket. This queue can grow as large as you allow it to grow. Of course you then use more memory.

What you will have then is a consumers/producer paradigm. One thread is putting things in the queue, other threads are taking from the queue.

If the processing of the threads is slower than the thread which is filling the queue, and this keeps going for a long time. Your queue is anyhow going to get overrun.

There are frameworks dedicated to the task of multimedia processing. You might want to take a look at gstreamer. http://gstreamer.freedesktop.org/documentation/ It has support for RTP and is basically a system that allows to create a pipeline of a datastream which is exactly what you are doing here.

You will find that gstreamer has ready made queues that allow to queue up some data somewhere in the pipeline. This anyhow proves to me that something like this is needed when you are processing at high speeds. Though I am not a gstreamer specialist. Gstreamer has building blocks so you can experiment with a pipeline and easily add queueing, remove it and compare the results of the overall pipeline. It does require some studying to get to know the api. It is written in C.

Answer 2

The more sockets you have, the more socket receive buffers you have, so the more space is available for incoming data.

This suggests that multiple socket may be the better option.

However datagrams can be lost anywhere, not just at the target host.