[BXXPwg] Flow Control again

Steve Harris sharris@primus.com
21 Jul 2000 08:24:01 -0700


JohnnyXia@acersoftech.com.cn writes:

[...]

> If advertising a smaller window or "shrinking the window" by the
> receiver is discouraged, how can the receiver tell the sender to
> slow down its speed? Is there anyone who can show me an example?

"Shrinking the window" does not refer to changing subsequent promises
about available buffer space. It refers to changing your outstanding
promise about your available space.

In BXXP, the only thing the spec. mandates is that a channel will be
able to accept 4096 octets *once*. If that channel never extends its
window past that first filling of 4096 octets, that's still *not*
"shrinking the window." Shrinking the window would mean that after a
peer had sent 2048 octets with an assumed window of 4096, the receiver
then advertises a window of size, say, 10. That means that 2038
previously-available octets disappeared!

Another good metaphor is shopping on borrowed money. You agree to lend
me $4096. I go spend half of it on my credit card at one store, then
go looking around for something else to buy, thinking I have $2048 of
credit left. I buy something on the card for another $1000. Seeing
that I'm not far from my limit, I call you to see if you'll send over
the $4096 before the credit card bill arrives. Not only am I expecting
you to send the original $4096 check, but also maybe offer me up even
more credit for the next shopping spree.

But instead you say, "Oh, hey, sorry, I can only give you
$2058. That's it." You just "shrunk the window," and now I'm in
trouble. You're permitted to say, "Sure, I'll send the $4096, but I
can't loan you anything after that." That's not shrinking the window,
because if I spent in accord of your promise, no one has over-spent
and everyone gets paid.

See this "TCP Persist Timer" chapter╣ from Stevens' _TCP/IP
Illustrated_ for a good discussion of window size management.


> I have gone through the source codes of SpaceKit for Java. From the codes,
> I see that when receives a REQ or RSP message, it will send a SEQ message.
> But when receives a SEQ message, it does nothing.

That sounds odd. It should be updating its record of how much more it
can send on the channel the SEQ message referred to.


Footnotes: 
╣ http://www.dqc.org/~chris/tcpip_ill/tcp_pers.htm#22_3

-- 
Steven E. Harris
Primus Knowledge Solutions, Inc.
http://www.primus.com