> On Aug 9, 2023, at 8:03 PM, Андрій Олексійович Радченко > <aoradchenko.fsh...@kubg.edu.ua> wrote: > > The problem isn't with the network, but with the likelihood that the client > or even the network itself might glitch. Can we really expect a system that's > working fine now to continue operating smoothly in the coming days? And if > such a glitch occurs, we get a closed stream instead of a recovery, even > though recovery is entirely possible, and what's more, it works if the server > doesn't close the stream. That's what I'm trying to say.
If the server's operating system’s buffer (for implementing TCP) fills up so much that a blocking write to a TCP socket fails, then this is more than just a ’network glitch’. It shows that (once again) you have been trying to stream at a faster rate than your network can support. You can delay this happening - by increasing your OS’s buffer (by calling “increaseSendBufferTo()”) - but it’s unlikely that you will be able to prevent it, unless you reduce the bitrate of your stream. > Of course, we can close the entire session, and then start it again. However, > in the event of a prolonged glitch, a lot of data will be lost (this is > important for surveillance systems, for example) due to constant > reconnections. In this context, simply not closing the stream seems a much > better option than reconnecting. So, my final question: what critical thing > could happen if we don't close such a stream but continue to work with it? If a blocking write to a TCP socket should fail, then there is little likelihood that any future write to that socket will ever work. Closing the socket is the best thing to do, as it allows higher-level software to recover. There will be no change to the software here. 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
