[BEEPwg] question about BEEP tcp mapping
Thu, 7 Feb 2002 17:30:08 -0500
I've been reading through the BEEP RFCs (3080, 3081) and I was hoping
someone here could help me understand the TCP mapping better.
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
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?
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