This is a discussion on Re: Question performnace of SSH v1 vs SSH v2 within the OpenSSH Development forums, part of the Networking and Network Related category; Gert Doering wrote: > Hi, > > On Mon, Feb 28, 2005 at 02:09:34PM -0500, Michael A Stevens ...
|
|||||||
| FAQ | Members List | Calendar | Search | Today's Posts | Mark Forums Read |
|
|||
|
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 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 openssh-unix-dev@mindrot.org http://www.mindrot.org/mailman/listi...enssh-unix-dev |
![]() |
| Thread Tools | |
| Display Modes | |
|
|