[Live-devel] Socket of RTSP-Server still blocked, when restarting the application

[Ross Finlayson]

On Aug 9, 2011, at 8:03 AM, Johannes Ebersold wrote:

> I am facing a problem with the binding of the port of the RTSP-Server. The Port used  by the server is not freed correctly, although the applications ends correctly is not killed using ctrl-c, as described here:http://www.mail-archive.com/live-devel@lists.live555.com/msg06837.html

Actually, if you read the follow-up messages in that thread, you'll see that the port (and socket) used by the server *is* freed correctly.  However, the TCP protocol implementation (in the operating system) deliberately waits a few seconds afterwards before it can mark the TCP connection as being completely closed (and thus before the port can be reused by another server application (or rerunning the same server application).

For more information, see
	http://www.unixguide.net/network/socketfaq/2.7.shtml
	http://developerweb.net/viewtopic.php?id=2941
and
	http://www.ssfnet.org/Exchange/tcp/tcpTutorialNotes.html
in particular:
	"The main thing to recognize about connection teardown is that a connection in the TIME_WAIT state cannot move to the CLOSED state until it has waited for two times the maximum amount of time an IP datagram might live in the Internet. The reason for this is that while the local side of the connection has sent an ACK in response to the other side's FIN segment, it does not know that the ACK was successfully delivered. As a consequence this other side might re transmit its FIN segment, and this second FIN segment might be delayed in the network. If the connection were allowed to move directly to the CLOSED state, then another pair of application processes might come along and open the same connection, and the delayed FIN segment from the earlier incarnation of the connection would immediately initiate the termination of the later incarnation of that connection."

There *is* a potential hack (involving SO_LINGER, as noted in the original thread) that could eliminate this delay.  However, it's non-portable, and introduces the (albeit remote) possibility of incorrect behavior.  So, I won't be adding this to the code.

If you close a server, just be patient (and wait a few seconds) before trying to restart it again.


Ross Finlayson
Live Networks, Inc.
http://www.live555.com/

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.live555.com/pipermail/live-devel/attachments/20110809/5abbc9b0/attachment-0001.html>