[BEEPwg] question about BEEP tcp mapping
Thu, 07 Feb 2002 14:57:23 -0800
Michael Fortson wrote:
> I don't really understand why the use of SEQ frames and a sliding window
> is necessary to avoid starvation and deadlock when the underlying
> transport (tcp) already addresses these problems (although for ports,
> not channels).
For the same reason that TCP has a window for each port.
> For instance, why can't the underlying TCP socket deal
> with ensuring that peers don't send more data then the other can
They do. But what prevents channel 5 from overrunning the processing at
the peer and thereby making channel 7 have to wait for unrelated
Say you have two streams, channel 5 getting copied to the printer,
channel 7 going to the disk. If the printer is very slow, channel 7
might get held up waiting for channel 5 to drain a large block of 20
pages of text. If channel 5's window is smaller than the printer's
buffer and doesn't get opened wider than the printer's buffer, channel 7
will never slow down.
> Incidentally, I realize that I'm missing something -- I'm just hoping to
> arm someone with enough ammunition to quickly point out what I've missed
You're not missing something. You just don't realize you already know
San Diego, CA, USA (PST). Cryptokeys on demand.
The opposite of always is sometimes.
The opposite of never is sometimes.