Subject: Re: [libssh2] PEM file reader and another libgcrypt status update

Re: [libssh2] PEM file reader and another libgcrypt status update

From: Daniel Stenberg <>
Date: Wed, 24 Jan 2007 09:54:29 +0100 (CET)

On Wed, 24 Jan 2007, Mononen Jussi wrote:

> One code based bottleneck has been identified long time ago, it was in the
> packet.c and in the function packet_read which read only 16 bytes at a time.
> Afaik this has been correct.

I have two entirely rewritten functions for the lower level packet read and
write, so now we can tweak the buffer sizes to better match what is typically
used in the protocol. Currently I use a 4096 bytes buffer for the reading.

> As Sara mentioned in one of her earlier mails to this list other SSH
> implementations (eg. OpenSSH sftp) use scattershot techniques (asynchronous
> transfer) where several packets are sent immediately and responses (and
> their ordering) is taken care of later when they arrive. This way the
> bandwidth is utlized much more efficiently as it can be used to send data
> while the remote end is processing previous messages.
> How to achieve this with an API like libssh2 is a problem to be solved. But
> the current synchronous transfer is appr. 50% slower than OpenSSH sftp.

I don't understand how the API is a limiting factor here. The application
certainly will want the data to arrive in order no matter how the API is
designed or how the internals work, and collecting data out-of-order can be
done while still offering the existing API. Or perhaps I'm missing

Take Surveys. Earn Cash. Influence the Future of IT
Join's Techsay panel and you'll get the chance to share your
opinions on IT & business topics through brief surveys - and earn cash
libssh2-devel mailing list
Received on 2007-01-24