DynamicWindow Patch

[Michael Stevens]

> > -     if (len > 0x100000)
> > +     if (!buffer->unlimited && len > 0x100000)
> >               fatal("buffer_append_space: len %u not supported", len);
> 
> that's dangerous, is it really necessary? we could
> crank the 0x100000.

I'm not sure I see where the danger is coming from besides memory
consumption when the  user locally sets a large window. The problem I
see with that is now instead of unlimited, you can only go up to that
static size. The unlimited flag is only set for the buffers in/out
buffer on the channel.

> 
> > +             u_int32_t tcpwinsz = 0;
> > +             socklen_t optsz = sizeof(tcpwinsz);
> > +             int ret = -1;
> > +             u_int32_t addition = 0;
> > +             if (c->dynamic_window)
> > +                     ret = getsockopt(packet_get_connection_in(),
> > +                             SOL_SOCKET, SO_RCVBUF, &tcpwinsz, &optsz);
> > +             if (c->dynamic_window && (ret == 0) &&
> > +                 (tcpwinsz > c->local_window_max)) {
> > +                     addition = 2 * tcpwinsz - c->local_window_max;
> > +                     c->local_window_max += addition;
> > +             }
> 
> why do you need to do this here? why not just announce a bigger
> window when the channel is created?
> 
> does SO_RCVBUF change during the session? otherwise we could do
> this instead.  but i agree, we should really improve the WINDOW_ADJUST
> handling.

It is specifically to allow the ssh window to grow when the tcp window
does. There are tools that allow you to change the tcpbuffer while the
program runs, autotuning tcp stacks being one of them.

Mike