[BEEPwg] question about BEEP tcp mapping

Darren New dnew@san.rr.com
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
> receive?

They do. But what prevents channel 5 from overrunning the processing at
the peer and thereby making channel 7 have to wait for unrelated
processing?

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
the answer.

-- 
Darren New 
San Diego, CA, USA (PST). Cryptokeys on demand.
  The opposite of always is sometimes.
   The opposite of never is sometimes.