Hello!
I work on a win32-based project that consumes live555 (client-side only) and
recently upgraded from an older synchronous API revision of live555 to the
latest (2015-06-11 at the time of this writing). Also, possibly of note, this
project is multi-threaded and consumes multiple instances of RTSPClient (with
separate UsageEnvironment(s), MediaSink(s), and MediaSession(s) per derived
RTSPClient instance).
My main concern is that the timeout parameter is missing from the calls and I
was previously using the timeout parameter to solve a silly win32 bug (as far
as I know it's win32-only). After the first connect(), subsequent calls to
connect() with a non-blocking socket will fail most of the time with EBADF (-9)
in a multi-threaded environment (e.g., in a thread-pool environment). To
combat this in the older API I specified a -1 on the first call (e.g.,
sendOptionsCmd) so that the initial socket would be in blocking mode upon first
connect(). The socket could then be made non-blocking after that point.
I can 'remedy' this problem by making RTSPClient::connectToServer() virtual and
using makeSocketBlocking() with an arbitrary timeout and then
makeSocketNonBlocking() after successful return from
RTSPClient::connectToServer(). I understand that this probably violates the
license agreement and in order to comply with the license, I ask: Is there a
way that live555 could be modified by making RTSPClient::connectToServer a
virtual method? Another way could be to allow a timeout per request, but at
the expense of more code and possibly more API changes.
My end-goal is that the connect() method can be called with a blocking socket
and a specifiable timeout. Simple example assuming the method was virtual and
MyRtspClient derives from RTSPClient:
<code>
int MyRtspClient::connectToServer(int socketNum, portNumBits remotePortNum) {
...
makeSocketBlocking(socketNum, myOwnTimeoutValue);
...
int result = RTSPClient::connectToServer(socketNum, remotePortNum);
...
if(result >=0){
makeSocketNonBlocking(socketNum);
}
...
return result;
}
</code>
Side note: this is one of the few instances of this issue outside of Live555
that I could find while researching:
http://acsutoday.blogspot.com/2009/02/connect-returns-ebadf-when-run-in.html
Thanks for the great RTSP library and thanks in advance for your time.
-karl
This message and any attachments are solely for the use of intended recipients.
The information contained herein may include trade secrets, protected health or
personal information, privileged or otherwise confidential information.
Unauthorized review, forwarding, printing, copying, distributing, or using such
information is strictly prohibited and may be unlawful. If you are not an
intended recipient, you are hereby notified that you received this email in
error, and that any review, dissemination, distribution or copying of this
email and any attachment is strictly prohibited. If you have received this
email in error, please contact the sender and delete the message and any
attachment from your system. Thank you for your cooperation
_______________________________________________
live-devel mailing list
[email protected]
http://lists.live555.com/mailman/listinfo/live-devel
