Re: Question performnace of SSH v1 vs SSH v2

Michael A Stevens wrote:
> There is also another subtle issue of how often should the window be
> polled. Polling the tcp window on a WINDOW_ADJUST message could prove to
> be costly if they happen very often.

At the very real risk of rapdily showing my ignornace of what is implied in the
receipt of a WINDOW_ADJUST message...

The TCP window - or rather, what gets reported in a
getsockopt([SO_RCVBUF|SO_SNDBUF]) - will not change during the life of a TCP
connection unless the application makes a corresponding
setsockopt([SO_RCVBUF|SO_SNDBUF]) call. So once after the connection is
established should suffice. Again after any setsockopt call. The reason being
that while every other stack I have encountered in N years of netperf reports
back what setsockopt() asked for (modulo limits) - Linux seems to report up to
2X the setsockopt() value (again modulo limits).

And, if the remote makes a setsockopt() call, there is no (portable) way to get
the remote's advertised window anyway - we can only see what our socket buffer
sizes happen to be.

rick jones

BTW, unless the stack has negotiated window scaling when the TCP connection was
established (wscale on the SYN segments), there will be a hard limit on the TCP
window of 65535 bytes even if the socket buffer sizes are greater. I've seen
that _some_ stacks will use window scaling when the window is < 64KB, but that
is not universal.

_______________________________________________
openssh-unix-dev mailing list
openssh-unix-dev@mindrot.org
http://www.mindrot.org/mailman/listi...enssh-unix-dev