Ross Finlayson wrote:
No, that's not correct. The RTSP server implementation's 'liveness
check' timer gets rescheduled only after the receipt of an incoming
*RTCP packet* (or an incoming RTSP command) - not on every (or any)
outgoing packet.
Ah good, that makes a great deal more sense.
However, I don't want to use the STL,
because I don't want to make the "LIVE555 Streaming Media" dependent
upon it (because I want this code to continue to be useful for (e.g.)
embedded systems that are relatively memory constrained, or which
might not have the STL available for other reasons).
Yeah, that makes sense, too. I certainly wouldn't attempt to write the
equivalent of the STL class (a Red-Black tree) myself. I agree that the
current implementation is perfectly fine for most uses. Largely, I'm
offering a tip to others that may find themselves in my situation about
where to look for performance.
At some point, I should get rid of these (few) remaining blocking
socket reads, and remove the "select()" call from "readSocket()".
Actually, as you're just running a RTSP server, you can probably
remove the "select()" call right now. You could give that a try, to
see if it improves performance on your system.
Yes, I did this. The figures of 400-500 sessions I quoted had the call
to blockUntilReadable commented out.
Marc Neuberger
_______________________________________________
live-devel mailing list
live-devel@lists.live555.com
http://lists.live555.com/mailman/listinfo/live-devel
