On Tue, 3 May 2022, rapier wrote:
> Hey all,
>
> Hopefully this is an easy question. In channels.c what is
c->remote_window
> being used for? Does it correspond to c->local_window on the remote?
Does it
> indicate free space in a buffer? If so which one? I'm trying to nail
down a
> stalling situation.
AFAIK it is used to record the most recent peer window value (i.e. sent
via SSH2_MSG_CHANNEL_WINDOW_ADJUST) minus whatever data has been sent since
then. It is used to avoid sending more than the peer's advertised window
between receipt of SSH2_MSG_CHANNEL_WINDOW_ADJUST messages
It therefore roughly corresponds to c->local_window on the peer, but only
after you take into account data that is in-flight or sitting un-acked in
the peer's receive buffer.
I guess you'd call remote_window "the estimate of the remaining bytes
available in their last-advertised window".
> On the client I've put in a debug line into channel_input_window_adjust
to
> report on the size of the c->remote_window. I've noticed that when
the
> performance drops and seems to stall this value doesn't move much at
all. So
> I'm wondering if this represents a buffer on the remote reaching a
maximum
> size and waiting to drain.
If you can similarly instrument the peer, then it might shed some light on
it. Some possibilities:
1) heaps of data in flight (e.g. bufferbloat on intervening routers)
2) a peer with a full output buffer for the channel, e.g. if it was
writing to a disk that is slower than the network. This will cause
backpressure via c->local_consumed (see end of channel_handle_wfd())
3) some stupid bug where we miss a case to update c->channel_handle_wfd
or do the math wrong in channel_check_window()
hope this helps!
-d