[BEEPwg] (no subject)

Michael Fortson mfortson@nyc.rr.com
Wed, 20 Feb 2002 17:00:12 -0500


Marshall & Darren, thanks for the help on this - I think I was stuck
considering the case were all channels were serviced equally well (so it
becomes the problem of the beep client layer to hold onto un-received
data until an application grabs it), despite this not being a required
(or even likely, now that I think about it) implementation. 

Incidentally, sorry for responding so late -- been having some mail
server problems...

-Michael


-----Original Message-----
From: beepwg-admin@lists.beepcore.org
[mailto:beepwg-admin@lists.beepcore.org] On Behalf Of Marshall Rose
Sent: Thursday, February 07, 2002 5:48 PM
To: Michael Fortson
Cc: mrose@dbc.mtview.ca.us; beepwg@lists.beepcore.org
Subject: Re: [BEEPwg] question about BEEP tcp mapping

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

/mtr
_______________________________________________
BEEPwg mailing list
BEEPwg@lists.beepcore.org
http://lists.beepcore.org/mailman/listinfo/beepwg


-----Original Message-----
From: beepwg-admin@lists.beepcore.org
[mailto:beepwg-admin@lists.beepcore.org] On Behalf Of Darren New
Sent: Thursday, February 07, 2002 5:57 PM
To: beepwg@lists.beepcore.org
Subject: Re: [BEEPwg] question about BEEP tcp mapping

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.
_______________________________________________
BEEPwg mailing list
BEEPwg@lists.beepcore.org
http://lists.beepcore.org/mailman/listinfo/beepwg