Subject: Re: [PATCH] Send internal packet priority

Re: [PATCH] Send internal packet priority

From: Daniel Stenberg <>
Date: Fri, 9 Sep 2011 08:47:14 +0200 (CEST)

On Fri, 9 Sep 2011, liuzl wrote:

First, thanks a lot for your hard work and patience.

I spent some time yesterday trying SFTP transfers on Linux with *huge* buffers
without being able to see any of these problems. :-(

> Yes, the return code of _libssh2_channel_receive_**window_adjust() is
> LIBSSH2_ERROR_SOCKET_SEND because we are blocking in the last call. then
> function _libssh2_channel_read() will ignore LIBSSH2_ERROR_SOCKET_SEND,

Aha, but that's a bug. Let's do this:

--- a/src/channel.c
+++ b/src/channel.c
@@ -1881,7 +1881,7 @@ ssize_t _libssh2_channel_read(LIBSSH2_CHANNEL *channel,
             this special state here */
          rc = _libssh2_channel_receive_window_adjust(channel,
+ if (rc)
              return rc;

          _libssh2_debug(session, LIBSSH2_TRACE_CONN,

The next step is then to figure out why the receive window function fails in
your tests - I keep trying but I can't repeat these problems which makes
things a little difficult for me.

> In my first patch for this problem i send the receiving-window-adjust
> packet in _libssh2_channel_write(), the packet can be sent before
> we are blocking, see:

No fix that includes some kind accepting that BAD_USE is returned can be fine
to me. BAD_USE must never be returned as when it is, we've used the internal
functions wrongly and we need to fix that first.

I've instead tried to understand why it would occur and I'm trying to address
those issues.

> Second, if _libssh2_channel_receive_window_adjust() return EAGAIN, caller
> will get a big problem.

When and how?

Before my patch (which I've now pushed btw) it could easily go wrong, I agree.

When receive_window_adjust() returns EAGAIN to channel_read(), surely
channel_read() will be called again? (Or have you identified a call path when
it fails to do this?) And when it is, it now goes directly back to
receive_window_adjust() to complete that operation...

Received on 2011-09-09