[Live-devel] non blocking sockets

[jers at inwind.it]

> >  > >I noticed that in the library the RTSPServer as well as the RTPSink
> >>  >makes use of only blocking read/write system calls.
> >>
> >>  That's not true.  Both the TCP sockets (for RTSP control) and UDP
> >>  sockets (for RTP) are set up as non-blocking.
> >
> >you are right, they are setup as default non-blocking,
> >anyway the real use seems to be blocking.
> >I mean:
> >The RTSPClientSession receives from the RTSPServer a non blocking 
> >TCP socket. Then in the incomingRequestHandler1()
> >it calls the readSocket (with NULL timeout parameter).
> >The readSocket calls the blockUntilReadable() and this function does 
> >a select() with a single file descriptor (the socket) in its fdset.
> >I think that this blocks the process.
> >Do you agree?
> 
> No, because the sockets get read only when new readable data becomes 
> available (within the event loop).  (This is what the calls to 
> "TaskScheduler::turnOnBackgroundReadHandling()" do.)  Because of 
> this, the socket reads end up being non-blocking, because they are 
> called only when new data is available.  (In this case, the 
> "blockUntilReadable()" call doesn't actually 'block'; blocking 
> happens only if a socket is read when no incoming data is actually 
> available (but the RTSP server code never does that).)
> -- 


Dear Ross,

Ok, obviously you are right! Sockets generated in the RTSPServer are not blocking but, if during a RTPOverTCP streaming, the connection with the player goes down (I have unplugged the cable), the server stays blocked at the send() call. This problem is due to the accept() function in RTSPServer::incomingConnectionHandler1(). It  returns only blocking sockets even if the main socket is not blocking. I solved the problem setting as NONBLOCK the socket after the accept() call
 it seems to work. Do you think that my solution can cause other uncontrolled mishaps?

Moreover,  a problem about blocking socket it seems to be also in the RTSPClient. In this case too, I need to use RTPOverTCP connection. In RTSPClient::openConnectionFromURL() is called the setupStreamSocket() with the third argument (i.e. makeNonBlocking) set to False. Is this a free choice or must I keep this setting? Having to write a software that manages more clients, this choose might to be very harmful for my process. 

Ragards
Jers



------------------------------------------------------
Ordina subito la scintillante lampada a forma di Renna di Babbo Natale: lascerai i tuoi ospiti... a bocca aperta !
http://click.libero.it/dmail06dic06