[BEEPwg] question about BEEP tcp mapping

Marshall Rose mrose@dbc.mtview.ca.us
Thu, 7 Feb 2002 14:47:49 -0800

> 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 instance, why can't the underlying TCP socket deal
> with ensuring that peers don't send more data then the other can
> receive?  

with rfc3080, it's possible that you have more than one data exchange channel simultaneously active. in this case, you need to have a mechanism wherein the beep peers can negotiate how much each channel gets.

otherwise, you can get into a situation where one channel starves another one, potentially even channel 0...

> As far as BEEP flow control goes, would it be possible for peers to
> negotiate a larger max-frame-size (restricted by 2/3rds of the TCP
> max-segment-size) rather than increase the size of their windows?

i'm not sure i follow what you're asking exactly. you can implement whatever algorithms you want, providing they are consistent with the guidelines given in rfc3081, e.g., priority queues.