Re: adjust strategy
- From: attila.r.nohl@xxxxxxxxx
- Date: Sat, 28 Mar 2009 07:25:57 -0700 (PDT)
On márc. 28, 12:49, Simon Tatham <ana...@xxxxxxxxx> wrote:
Consequently the Erlang server also sent a couple of small adjust
messages which somehow confused the Maverick client to send only
small messages and the whole upload didn't work.
By 'didn't work', do you mean that something actually _failed_, or
just that the correct data was exchanged but only in extremely small
fragments leading to a very slow connection?
The server started to use 100% CPU and eventually the data transfer
stopped. I'm not sure that this was due to some timeout in an
application level above the SFTP layer - usually I stopped the
testcase, because the slowness is also unacceptable in this case.
If the former, it sounds as if the client is actually broken, in the
sense that it is receiving a packet stream consistent with the spec
and not coping with it. Rather than trying to modify the server to
avoid triggering the client bug, you should find the client bug and
I only have access to the server source, that's why I tried to change
things there :-)
I've changed the implementation in the Erlang server to only send an
adjust message if all fragments are received. This seems to work, but
I'm not sure if this is correct according to the specifications - is
No. If the client wants to send an SFTP packet which is greater than
the SSH channel's window size, it MUST send no more than the first
windowful of data and then wait to receive a WINDOW_ADJUST before
sending any more. Therefore, you MUST be willing to send a
WINDOW_ADJUST in the middle of receiving an SFTP packet, if the
packet is large enough.
If you absolutely must solve this problem by fiddling with the
server's window adjust strategy rather than fixing the client to
cope with anything legal it receives, a simple option would be to
send WINDOW_ADJUST only once your window drops to half its original
size, which would mean you'd still send them in the middle of large
packets but wouldn't send too many very small ones.
So the current solution breaks the protocol. I'll look at this
solution, because I'd prefer not to break compatibility with other
I am surprised to hear that any implementation - client _or_ server[...]
- has this much cross-talk between its ssh-connection layer and its
I'm working with an older version of the Erlang SSH server. The newer
one seems to be better separate the SSH and SFTP layers. Unfortunately
that doesn't work either (the upload stops after a while), but that's
another debugging session :-)
- Prev by Date: Re: adjust strategy
- Next by Date: Re: SSH key limited ONLY to port forwarding? Possible?
- Previous by thread: Re: adjust strategy
- Next by thread: Re: SSH key limited ONLY to port forwarding? Possible?