Steinar H. Gunderson wrote:
On Thu, Jan 12, 2017 at 04:59:33PM +0000, Andy Furniss wrote:
I've seen plenty of "legal" shrinks looking at tcpdumps - usually the
app is throttling it's read speed.
You're not really allowed to shrink by more than you've received, though,
are you? Typically the buffer going down is just that the app hasn't read all
the data from the socket -- but that's a different case.
Correct - I was probably being over pedantic about one statement in the
context of buffer sizes.
The point of the “no-shrink” rule is that once you've advertised a window to
the sender, the sender should be allowed to send that much data with no ack,
Yes.
without keeping a copy, and without worrying it might get lost. If you could
shrink the window, that guarantee would disappear.
Not so sure about this bit = when the ack comes it may well inform that
a re-transmit is needed.
_______________________________________________
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
