Subject: Re: client-side only vs. libssh?

Re: client-side only vs. libssh?

From: Aris Adamantiadis <>
Date: Sat, 23 Jan 2010 01:15:53 +0100

Hi Daniel, others,

While you are at it, I am thinking about that "libssh2 vs libssh" page
[1] which is disturbing me since a good time. For the followers of this
thread, I am the libssh[2] founder and one of the few developers.
Let me develop my objections to this page:

-"not threadsafe": libssh is as much threadsafe as libssh2, in the
sense that all operations made on different sessions are threadsafe.
That is consistent with "Thread-safe: just don't share handles
simultaneously" on front page[3].

-"Some limitations on >4gb files": Not any that I am aware of. Could
you explain what's actually lacking in libssh 0.4 ? There is a
sftp_seek64 call which takes a uint64_t parameter. That function exists
since 0.3 released one year ago.[4]

-"Optional libgcrypt support": there is full libgcrypt support in
libssh since 0.2 release, which was released at least 4 years ago. The
support for libgcrypt is written in plain text in the "about" page of
our site, 3 lines before the "thread safety" claims.[5]

-Speed claims: Please don't be ridiculous. No competent network
developer will take you seriously when you tell that libssh2 is 2.3
times faster that libssh. I am amazed that nobody ever discussed your
"benchmark method" [6].
The benchmark was made that way : you cat'd some big file in a channel
of samplessh and saw that it was slower than the libssh2 scp thing.
Would that person have read the source of the program he used, he'd
have seen that
1- Purpose of this program was to test the console interactivity
features of libssh.
2- As the goal was to test the features, the input buffer was set to 10
bytes and output was not buffered.
3- The "benchmark" was done without any protocol or specifications.
Testing a network protocol using a file on the local hard disk on
localhost is a beginner's mistake. Not even telling anything about the
cryptographic algorithms chosen for the test. I am not saying that
libssh 0.3 may or may not be slower than libssh2, I am saying that it's
ridiculous to make precise speed claims out of that single biased test.

I wanted to develop a complete benchmark testbed, including perfectly
similar tests for libssh, libssh2 and openssh, in order to test these
claims. But finally my time is restricted and I prefer coding useful
features, so I decided to invest time in the next version of libssh.

I do not discuss the license of libssh and the blocking issues. These
are real and will hopefully be resolved in next major libssh release.

In short, the diff I propose to that page is the following:
libssh2 1.2
-# is thread-safe
-# is much faster than libssh (2.3 times faster for raw SSH has been
-# optionally runs with libgcrypt instead of OpenSSL for the crypto layer
-libssh 0.3
+libssh 0.4
-# is not thread-safe
-# has some limitations on >4GB files on 32bit systems

-Limits on >4GB files yes yes
+Limits on >4GB files yes no
-Optional libgcrypt crypto yes no
+Optional libgcrypt crypto yes yes
-Relative SSH transfer-speed 2.3 1

Don't take it as a personal offense. I think a bit of competition in
opensource is fair and leads to innovation, when it is fair. I hope we
can both also work on some constructive document which would guide the
newcomers into a choice between the two possibilities, instead of
misleading them with wrong or outdated info.
Thanks for reading until that point and for your attention :) I am of
course available for remarks and comments.

With kind regards,

Aris Adamantiadis,
libssh project Founder and lead.


Received on 2010-01-23