> On Jan 1, 2020, at 7:27 AM, Jeff Shanab <jsha...@jfs-tech.com> wrote: > > I have, I think a unique problem that uses the same section of code so it > seems a good time to ask a related question. > > I have reuseFirstSource set because it is a live source. > In this test I have 2 or more clients connected, 1 of them is a slow consumer > causing the OS to backup the socket until a send failure, but then it > reconnects immediately. > > What is the recommended way of handling multiple TCP consumers well, when 1 > of them is slow to consume and quick to reconnect.
If a RTP-over-TCP connection is so slow that it is eventually filling up the sender OS’s buffer, then that means that it’s exceeding the capacity of the TCP connection (which is based in part on the loss rate of the connection between the server and client). In this case it’s more efficient to stream over UDP instead. Either way, you’ll get data loss, but the overall data loss rate will be less than it will be over the TCP connection. Over TCP, the data loss will be clumped together (at the time(s) when the sender OS’s buffer keeps filling up), and the overall end-to-end latency (between sender and client) will be lower. I don’t know how many times I have to keep saying this, but you should stream over TCP *only if* you have a firewall - between the server and client - that blocks UDP packet. You should never stream over TCP just because you want to avoid data loss. If your stream’s data rate exceeds the capacity of the network connection (server->client), then you *will* lose data, no matter how you choose to stream it. In this case, if you want to avoid all data loss, you should be copying your data using something like HTTP, rather than streaming it. 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
