[Live-devel] Related to -> non blocking sockets

[xcsmith at rockwellcollins.com]

>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?

No, because "RTSPClient" currently reads its
responses synchronously, its socket must be
blocking.  (Having "RTSPClient" read its
responses synchronously is probably a design
flaw, because it prevents having multiple clients
- or a client and a server - running in the same
event loop.  This will probably get fixed
someday...)
--

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


Yes! I discovered that the combination of having a single thread
application, a blocking RTSP client, and RTSP server in the same
application is not going to work so well if the RTSP client contacts the
RTSP server in the same application (or I think an RTSP server that is
unavailable).  The client gets stuck waiting for the server to respond, but
the server can never receive the message because the event loop never moves
forward after the client read.

(Of course it is odd to contact RTSP server in your own application, but
actually my RTSP client starts an RTSP message chain that can eventually
result in my RTSP server being called to service the stream.)

I have been thinking about how to fix the client, but it seems that if,
instead of calling getResponse(), I turn on backgroundReadHandling and
return, then the only way to inform the client's user that the RTSP
conversation finished is with a callback.  Adding a callback would change
the interface design, and then all of the test apps would have to be
rewritten.  Also I would add a timeout function so that the user could
regain control if the server never responded or sent only a partial
message.  The server fix released in the last couple months seemed easier
because it is not as important to a server if a client never finishes its
message.

If I change at least my personal copy of RTSPClient to use callbacks do I
need to create the socket in a different way than call
openConnectionFromURL()?  Do you have a better idea than callbacks?

Also: If my comments about issues with related parts of the code are
considered thread hijacking plz say so!  I can always make my own topic
too; I am not sure of the etiquette.  Sorry if I've offended.

Thanks!
~medra