On Sun, 11 Sep 2011, Peter Stuge wrote:
> What does OpenSSH do in their SFTP client?
I have no idea. I've never studied the OpenSSH source code very close.
> Also see the plans for their GSoC project which had 8 or 9 bullet points for
> how to optimize their SFTP performance.
That's indeed a good idea.
But OpenSSH also have it much easier since they don't provide an API (that is
fixed) for this, they just need to optimize for their own command line tool.
>> libssh2_channel_read_ex(LIBSSH2_CHANNEL *channel, int stream_id, char *buf,
>> size_t buflen)
>
> Maybe buflen should not be used blindly.. Or maybe it should? Hmm.
> 320MB window is a big one.
If an application wants 320MB then surely we should tell the other side that
we can in fact receive that much? Or if there's a problem with that large
window/buffer we can just internally pretend that we got a smaller buffer...
Of course, lots of server implementations probably won't like that large
window so we must make sure libssh2 properly handly such situations as well.
I'm not sure what it does now.
> OTOH I don't know if it actually does any harm, and when considering that we
> now have send/recv callbacks it's even possible that the SSH protocol is not
> being used over TCP in the first place.
I don't see the connection to TCP here. The receive window has nothing to do
with the transfer layer protocol type. It is only about flow control.
> (Do we still require getting passed a socket for some reason, or is that
> optional with send and recv callbacks?)
If someone wants to do libssh2 over something else than TCP then I figure
there might be some tweaks needed. Most of it should work fine with the
callbacks I think.
-- / daniel.haxx.se _______________________________________________ libssh2-devel http://cool.haxx.se/cgi-bin/mailman/listinfo/libssh2-develReceived on 2011-09-11