Subject: ssh channel window and adjustment

From: Sombody Somewhere <[email-masked]>
Date: Tue, 14 Jan 2003 08:15:01 -0800 (PST)

Hi all,

I have a simple question about ssh channel window and
its adjustment. Maybe this is my mistake and I haven't
found the right info about it and sorry if it is a
lame
question for you. I am interested in the following
issues:

1. Does a SSH_MSG_CHANNEL_WINDOW_ADJUST message
consumes window size?
2. Is there a specific rule when to send
SSH_MSG_CHANNEL_WINDOW_ADJUST and when
not
to send it ?
3. What must a peer do, when it has to send data but
has no channel window ?

Thank you very much in advance for you replies.

__________________________________________________
Do you Yahoo!?
Yahoo! Mail Plus - Powerful. Affordable. Sign up now.
http://mailplus.yahoo.com

---

From: Jon Bright <[email-masked]>
Date: 14 Jan 2003 17:40:01 +0100

> 1. Does a SSH_MSG_CHANNEL_WINDOW_ADJUST message

No.  Unless I'm mistaken, the window size is the window for data sent in
the 'data' field of the SSH_MSG_CHANNEL_DATA and
SSH_MSG_CHANNEL_EXTENDED_DATA messages *only* - i.e. no other fields and
no other messages.  

> SSH_MSG_CHANNEL_WINDOW_ADJUST and when

No, this is implementation dependent.

> 3. What must a peer do, when it has to send data but

Buffer the data until the window is expanded.

-- 
Jon Bright
Lead Programmer, Silicon Circus Ltd.
http://www.siliconcircus.com/

---

From: Markus Friedl <[email-masked]>
Date: Tue, 14 Jan 2003 17:56:30 +0100

> 1. Does a SSH_MSG_CHANNEL_WINDOW_ADJUST message

no. only SSH_MSG_CHANNEL_DATA and SSH_MSG_CHANNEL_EXTENDED_DATA
consume window size.

> SSH_MSG_CHANNEL_WINDOW_ADJUST and when

no. depends on how you want to do flow control.

> 3. What must a peer do, when it has to send data but

send data on other channels, if possible.
buffer data received from other sources, if possible.

-m

---

From: Simon Tatham <[email-masked]>
Date: Tue, 14 Jan 2003 17:26:01 +0000

> 3. What must a peer do, when it has to send data but

There have been other good answers to your other questions, so I
won't spend time repeating them, but I haven't yet seen anyone say
what I want to say in response to this one.

If you have data to send on a channel but there's no window left on
that channel, then (as other people have said) your only option at
the SSH end is to sit on your buffered data and hope you get a
window adjust at some point in the future. Meanwhile you can still
send on _other_ SSH channels, and open new channels, and keep doing
everything else.

But the really important thing you probably want to do if you don't
have any window on a particular channel is to _stop accepting data_
from wherever your source is. For example, if the channel is a
forwarded port, this would be a good moment to stop reading data
from the relevant local network connection. That way, delays
propagate all the way down the pipeline: if the app at the server
end stops reading data, then the SSH server stops increasing the
window size, and when your client runs out of window it stops
reading data from the local connection, so eventually the app at the
client end sits there blocking and trying to send data - which is
exactly what it _would_ be doing if there wasn't an SSH connection
and a port forwarding in the way. To put it another way, you're
arranging that the total amount of data which can be buffered
between the ultimate endpoints of the connection is _limited_ - so
if the receiver stops receiving, the buffers will all fill up and
eventually the sender will notice.

If you don't do this, your SSH implementation will continue reading
data and buffering it, and will gradually inflate to a ridiculous
size and run out of memory.

Cheers,
Simon
-- 
Simon Tatham         "infinite loop _see_ loop, infinite"
<[email-masked]>     - Index, Borland Pascal Language Guide

---

From: Bill Sommerfeld <[email-masked]>
Date: Tue, 14 Jan 2003 12:59:54 -0500

[Note: WG chair hat off for the following]

> Buffer the data until the window is expanded.

Alternatively, provide some sort of flow-control back-pressure to slow
down the source of the channel..

For instance, if the data for the outbound direction of a channel
comes in on a reliable byte stream IPC channel of some sort [1], and
you run out of window on that channel, stop reading from the data
source.  The OS will provide buffering and/or back pressure to the
other end of that channel; when the channel's window reopens, you can
start reading that channel again..

						- Bill

[1] on unix: pipes, SOCK_STREAM sockets, etc.,

---

From: Sombody Somewhere <[email-masked]>
Date: Wed, 22 Jan 2003 04:20:08 -0800 (PST)

Hi all!

 Thank you for your replies. Basicly your opinions
confirmed my theory about the implementations and
standards ;).
Recently I investigated the OpenSSH client behaviour.
It seems to me that OpenSSH client sends
SSH_MSG_CHANNEL_WINDOW_ADJUST, when it writes more
than the half of its own channel window size(the
initial channel window size it is sending to its
peer,when opening new channel). I think that this
behaviuor may be quite incorrect. Here is an example
of such situation: let's say the user using OpenSSH
client sends commands to th SSH server and if we
suppose these  commands have big console output, then
OpenSSH client's channel window may be filled much
faster than the server's channel window space,but the
server is obliged no to write its output untill the
client sends it adjust message. This way the server is
 obliged to allocate great amount of data and keep it
allocated untill the the amount of data written by the
client exceeds the half of its own channel. Just then
the server will recieve adjust. In my opinion the
adjust message sneding has to be dependent on amount
of data read not written.
I would appreciate any comments on my opinion and
thank you again for your attention :)

P.S. I am afraid that this posting maybe treated as
out of topic but I think that people developing the
OpenSSH are reading this mail list and also I think
that if my opinion is generally wrong(having in mind
the drafts) this is the place to be corrected ;)

---

From: Jon Bright <[email-masked]>
Date: 22 Jan 2003 14:25:58 +0100

> than the half of its own channel window size(the

No, this isn't correct.  It sends it (afair, I don't have time to check
the code) when the remaining space in the incoming channel window is
less than half the maximum space in the incoming channel window.

>  obliged to allocate great amount of data and keep it

At no point is the server obliged to allocate lots of memory - it can
just stop accepting more data from whatever's generating the data.  So
if 'ls -lR' is generating the console output, the sshd stops accepting
the output from 'ls -lR', which in turn sleeps.  When the client sends
an adjust message, the server sends more data until the window's again
full.

---

From: Sombody Somewhere <[email-masked]>
Date: Wed, 22 Jan 2003 05:34:47 -0800 (PST)

Hi Jon!

I checked the code and I saw that I made a mistake -
sorry for the wrong post :( 
Thank you very much for the reply!