> The problem is user can remove the cable of TCP stream laptop and it stop > another client steaming UDP.
Too bad! As I said before, the write to TCP *has to* be atomic. If the write partly succeeds (i.e., if the initial, non-blocking call to "send()" returned a data count less than that provided (but >0)), then the remaining write *has to* succeed - otherwise the receiver will get inconsistent data; something that it doesn't expect to see over a TCP connection. That's why the blocking write is done. (Once again, this blocking write is done *only* in rare circumstances: when the initial, non-blocking write of packet data succeeded in writing only part of the data. ) Unfortunately there's no way for the code (or the OS, probably) to distinguish between the case where the write would block for only a short period of time (due to temporary network congestion), or indefinitely (e.g., due to someone unplugging a cable). The only way to prevent this is to reconfigure your server so that it does not support requests to stream RTP/RTCP-over-TCP. I have just released a new version - 2014.04.23 - that adds a new function "RTSPServer::disableStreamingRTPOverTCP()" that you can call on your newly-created "RTSPServer" object to reject client requests to stream RTP/RTCP-over-TCP. Ross Finlayson Live Networks, Inc. http://www.live555.com/
_______________________________________________ live-devel mailing list live-devel@lists.live555.com http://lists.live555.com/mailman/listinfo/live-devel
