GNOME Bugzilla – Bug 622757
gst-rtsp-server needs the SO_LINGER option to be set to reset the TCP connection immediately for port reuse
Last modified: 2010-08-20 14:18:13 UTC
I think gst-rtsp-server needs the SO_LINGER option to be set to reset the TCP connection immediately. linger.l_onoff = 1; linger.l_linger = 0; if (setsockopt (server->server_sock.fd, SOL_SOCKET, SO_LINGER, (void *) &linger, sizeof (linger)) < 0) goto linger_failed;
care to make a patch?
Wim, I can make a patch; against the tip? Best Regards, Rob Krakora
Attached is the patch. It actually needed to be make to gstrtspconnection.c in gst-plugins-base.
Created attachment 165427 [details] [review] Patch to set NO_LINGER option on RTSP TCP Sockets to allow immediate reuse of address/port combinations Here is the patch.
Created attachment 165428 [details] [review] Patch to set NO_LINGER option on RTSP TCP Sockets to allow immediate reuse of address/port combinations with new multicast address specification property Sent the wrong patch initially...here is the correct one...
Created attachment 165429 [details] [review] Patch to set NO_LINGER option on RTSP TCP Sockets to allow immediate reuse of address/port combinations with new multicast address specification property take 2... O.K., here is the final patch...it adds NO LINGER and settable multicast address property with default if not specified...
Commited the SO_LINGER part. I believe the configuration of the multicast address should be done on the media-factory. This would make it possible to have one server send on multiple multicast addresses depending on the media. commit 8f6fd320654f5390d72027ac289921f1f26e40b4 Author: Robert Krakora <rob.krakora at messagenetsystems.com> Date: Mon Aug 16 12:32:28 2010 +0200 server: use SO_LINGER SO_LINGER on the socket will make sure that any pending data on the socket is flushed ASAP and that the socket connection is reset. This makes sure that the socket can be reused immediately. Fixes 622757
(In reply to comment #7) > Commited the SO_LINGER part. I believe the configuration of the multicast > address should be done on the media-factory. This would make it possible to > have one server send on multiple multicast addresses depending on the media. > > > commit 8f6fd320654f5390d72027ac289921f1f26e40b4 > Author: Robert Krakora <rob.krakora at messagenetsystems.com> > Date: Mon Aug 16 12:32:28 2010 +0200 > > server: use SO_LINGER > > SO_LINGER on the socket will make sure that any pending data on the socket > is > flushed ASAP and that the socket connection is reset. This makes sure that > the > socket can be reused immediately. > > Fixes 622757 Wim, I agree that the multicast address should be done on the media-factory. Will this be a change that you will be making for an upcoming release or would you like me to take a stab at it and submit it to you for comments/suggestions/rework? Best Regards, Rob Krakora
(In reply to comment #8) > I agree that the multicast address should be done on the media-factory. I think it should even be done on the rtsp-media level, on second thoughts. This would then be similar to where you would configure the allowed protocols for a media resource. > Will > this be a change that you will be making for an upcoming release or would you > like me to take a stab at it and submit it to you for > comments/suggestions/rework? I don't plan on doing that myself, so patches are welcome.
(In reply to comment #9) > (In reply to comment #8) > > I agree that the multicast address should be done on the media-factory. > > I think it should even be done on the rtsp-media level, on second thoughts. > This would then be similar to where you would configure the allowed protocols > for a media resource. > > > Will > > this be a change that you will be making for an upcoming release or would you > > like me to take a stab at it and submit it to you for > > comments/suggestions/rework? > > I don't plan on doing that myself, so patches are welcome. Wim, I can work on this. I will submit a patch when it is complete. Would you like me to open a separate ticket for it? Best Regards, Rob Krakora
The SO_LINGER patch doesn't work so well after all. The problem is that right after the TEARDOWN reply has been sent to the client, the connection is closed. Because SO_LINGER is now off, it discards any data that might still be in the send buffers and sends a RST to the client. This sometimes causes the client to fail to read the reply of the TEARDOWN. I also tried to set the linger parameter to something else than 0, which causes the TCP stack to wait for this amount of seconds before clearing and reseting the connection. With a 5 second linger, this made things work again. Also, SO_LINGER doesn't seem to be well supported/implemented on all platforms. I'm considering revering the patch...
(In reply to comment #11) > The SO_LINGER patch doesn't work so well after all. > The problem is that right after the TEARDOWN reply has been sent to the client, > the connection is closed. Because SO_LINGER is now off, it discards any data > that might still be in the send buffers and sends a RST to the client. This > sometimes causes the client to fail to read the reply of the TEARDOWN. > I also tried to set the linger parameter to something else than 0, which causes > the TCP stack to wait for this amount of seconds before clearing and reseting > the connection. With a 5 second linger, this made things work again. > Also, SO_LINGER doesn't seem to be well supported/implemented on all platforms. > I'm considering revering the patch... I see your point and can confirm this... The problem seems to occur only when the client is killed and effectively "orphans" the connection anyway causing the timeout to have to end the connection on the server end. I ran into this debugging the client when I was abruptly killing it and restarting rapidly. Sorry if I wasted your time.
no problem. I disabled it for now but there is still a define in the code just so that we don't forget about it. commit af732fa7492c592c6ce7fd8b6092354e64f4675b Author: Wim Taymans <wim.taymans@collabora.co.uk> Date: Fri Aug 20 10:18:34 2010 +0200 server: disable use of SO_LINGER SO_LINGER cause the client to fail to receive a TEARDOWN message because the server close()s the connection.
(In reply to comment #10) > (In reply to comment #9) > > (In reply to comment #8) > > > I agree that the multicast address should be done on the media-factory. > > > > I think it should even be done on the rtsp-media level, on second thoughts. > I can work on this. I will submit a patch when it is complete. Would you like > me to open a separate ticket for it? yes, please.