[vlc-devel] rtcp and udp port collision

[Rémi Denis-Courmont]

On Sat, 23 Oct 2010 19:35:46 +0200, Sébastien Escudier
<sebastien-devel at celeos.eu> wrote:
> On Fri, 2010-10-22 at 20:40 +0300, Rémi Denis-Courmont wrote:
> 
>> I checked the VLC RTP output code. It ignores failure to create the RTCP
> 
>> socket (this is another bug). So it must be the client that fails.
> 
> What I observed, is the client allocated ports DEST/DEST+1, then the
> server allocated SRC/SRC+1, but failed because SRC+1 == DEST.

OpenRTCP() may fail, but the server will still stream. Only RTCP won't
work. Admittedly, this is a bug, as RTCP is really needed, e.g. for lip
sync. Currently, we ask the socket API for a free port, then try to get the
next one too. This is obviously unreliable.

We cannot loop until we get a pair of port successfully, because there is
no warranty that the loop will ever end. If the IP stack implements the
classic linear port allocation, this is very likely but not sure to work.
But some stacks allocate ports pseudo-randomly. This could turn into a busy
loop. (While unlikely, this could also turn into a live loop if several
tasks try to do this at the same time.)

We could share a single ports pair for all sockets pairs. However some IP
stacks, notably Linux, look up UDP sockets through hash table of a local
ports on the receive path. If there are many sockets on the same port but
with different peers, the receive path becomes really slow (been there done
that). And you really don't want the kernel to be slow. Furthermore, I
don't know if this would expose the server to a local denial of service:
could another application bind the same port and steal our traffic?

And then, we could use a single pair of sockets per stream, and use
sendto() for each client instead of send(). Unfortunately, this is not
scalable. We would have to share the fixed-size socket TX and RX buffers
for all clients. As such, we could hit packet loss when the buffers get
full. On the plus side, this would be very scalable for the IP stack, as
well as for the process. This would use only one pair of sockets per RTP
stream. Currently, VLC typically fails to handle more than  500 elementary
stream receivers at a time, due to the per-process file limit.

Unfortunately, I don't have the time and resources to evaluate the
potential performance bottlenecks with those two other ways of using
sockets. So I can't determine whether they would be viable solutions.

-- 
Rémi Denis-Courmont
http://www.remlab.net
http://fi.linkedin.com/in/remidenis