[Live-devel] RTSP server socket bind error

[Stathis Voukelatos]

Hi,



I run the 'testH264VideoStreamer' app and view the video with an RTSP
client (eg VLC).

If I kill 'testH264VideoStreamer' while the client is connected and then
try to run it again

straight away I get the following error:



Failed to create RTSP server: bind() error (port number: 8554):
Address already in use



I ran netstat and found that the cause of this error is that the socket
is in the TIME_WAIT

state. You need to wait until the TIME_WAIT timeout period elapses.

I found a way around this by editing the setupStreamSocket() function to
set the

SO_LINGER option with a timeout of 0 on the socket to force the server
to abort the

connection. Would that be a useful change to the code (maybe with a
linger timeout > 0 )

or would it cause other side effects?



Stathis

[Ross Finlayson]

Post by Stathis Voukelatos
I run the 'testH264VideoStreamer' app and view the video with an
RTSP client (eg VLC).
If I kill 'testH264VideoStreamer' while the client is connected and
then try to run it again
Address already in use
I ran netstat and found that the cause of this error is that the
socket is in the TIME_WAIT
state. You need to wait until the TIME_WAIT timeout period elapses.
I found a way around this by editing the setupStreamSocket()
function to set the
SO_LINGER option with a timeout of 0 on the socket to force the
server to abort the
connection. Would that be a useful change to the code (maybe with a
linger timeout > 0 )
or would it cause other side effects?

I'm not sure. This web page
http://developerweb.net/viewtopic.php?id=2982
suggests that SO_LINGER is not very portable, and might not always do
what you want. (Other references (e.g., Stevens' book) also notes
the (albeit remote) possibility of data corruption if you were to
restart a server before the TIME_WAIT period ends.) So I'd be
reluctant to add this to the code just to satisfy people's
impatience. Instead, just wait a few seconds, and you'll be able to
restart your server.

[Stathis Voukelatos]

Hi Ross,



Thanks for your reply. I agree that SO_LINGER is not the recommended way
of getting

round the TIME_WAIT state. I had a closer look at the RTSP server code
and realized that

the SO_REUSEADDR option is turned off at the server socket in
RTSPServer::setUpOurSocket()

and that is why the server cannot be restarted.



If I set the option by removing the creation of the dummy NoReuse
object, then the server can

bind again to the same port straight away as expected. Is SO_REUSEADDR
turned off just to avoid

data corruption (e.g. there is a remote possibility of data that is
hanging around from the old

dead connection to be inserted to the new TCP stream after the server is
restarted)?



Stathis

[Ross Finlayson]

Post by Stathis Voukelatos
Thanks for your reply. I agree that SO_LINGER is not the recommended
way of getting
round the TIME_WAIT state. I had a closer look at the RTSP server
code and realized that
the SO_REUSEADDR option is turned off at the server socket in
RTSPServer::setUpOurSocket()
and that is why the server cannot be restarted.
If I set the option by removing the creation of the dummy NoReuse
object, then the server can
bind again to the same port straight away as expected. Is
SO_REUSEADDR turned off just to avoid
data corruption (e.g. there is a remote possibility of data that is
hanging around from the old
dead connection to be inserted to the new TCP stream after the
server is restarted)?

No, SO_REUSEADDR (and SO_REUSEPORT) is turned off for the server for
a very simple reason: We can't have more than one server on the same
host using the same port at the same time! I.e., we don't want to
start a RTSP server on port 554 (for example) if the computer already
has a server running with that port. Similarly for the HTTP port
(for RTSP-over-HTTP tunneling, or HTTP Live Streaming): We can't have
the server use a HTTP port if there's already a HTTP server running
with that port. (That's why our code tries several different HTTP
port numbers in succession: 80, then 8000, then 8080.)

So, in conclusion: Don't change the code. If you end up having to
<control>-C a server, then just be patient and wait a few seconds
before starting it up again.

[Eric Lammerts]

No, SO_REUSEADDR (and SO_REUSEPORT) is turned off for the server for a
very simple reason: We can't have more than one server on the same host
using the same port at the same time!

On Linux you can't bind twice even with SO_REUSEADDR, so it might make
sense to make it a platform-dependent option.

Eric