[BEEPwg] question about BEEP tcp mapping
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
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.