> On Jan 12, 2017, at 11:04 AM, Steinar H. Gunderson > <steinar+ffm...@gunderson.no> 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. >
You’re correct, decreasing the advertised window by more than you’ve received (relative to last advertised window value) is what the term “shrinking the window” refers to. Check out RFC 793, section 3.7 Data Communication. http://www.faqs.org/rfcs/rfc793.html All that aside, I don’t think illegal window shrinking is that relevant to this patch because we are fetching the value of SO_RCVBUF each time before determining how to perform the seek (either read-ahead/discard or close/open new connection). > 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, > without keeping a copy, and without worrying it might get lost. If you could > shrink the window, that guarantee would disappear. > Joel _______________________________________________ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
