This is a discussion on Re: Question performnace of SSH v1 vs SSH v2 - openssh ; Gert Doering wrote: > Hi, > > On Mon, Feb 28, 2005 at 02:09:34PM -0500, Michael A Stevens wrote: > >>There also is a complication with just scaling the SSH window to a larger >>size because of a small bug ...
Gert Doering wrote:
> On Mon, Feb 28, 2005 at 02:09:34PM -0500, Michael A Stevens wrote:
>>There also is a complication with just scaling the SSH window to a larger
>>size because of a small bug in the channel code that grows a buffer to
>>something larger than the buffer check allows. This really shouldn't
>>happen though, as SSH should be able to depend on the underlying TCP
>>buffer to hold data that it has not fetched yet.
> If you have parallel streams, this will induce head-of-line blocking
> (session of one stream sits in the TCP buffer, blocking stuff for
> other channels).
How likely is that though? Actually, that question would be both for there being
more than one stream muxed over the TCP connection and for one of the streams to
fully block the others.
At one level at least, multiple streams over a single TCP connection sounds a
bit like multiple TCP connections over a data link.
Is there anything in the existing v2 code that precludes the blocking by say two
of three streams over the connection anyway?
Other pseudo-random thought:
Additional setsockopt() calls when streams are added. May not increase the
actual TCP window but it would allow the data to be buffered.
openssh-unix-dev mailing list