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

Re: client-side only vs. libssh?

From: Daniel Stenberg <>
Date: Sat, 23 Jan 2010 20:43:13 +0100 (CET)

On Sat, 23 Jan 2010, Lawson wrote:

> I'm looking for a common denominator that can be re-used. Yes NSS is built
> on top of NSPR.

Right, but building a lib on top of NSPR doesn't necessarily mean that the lib
works automatically fine just because NSPR happens to be fine.

> If it sounds trivial and you don't see the value that's fine, I may do it
> for my own use anyway. But the difference is the amount of [re-]testing I
> have to do to make sure a product is really behaving reliably.

You can't avoid that re-testing just because they all use the same socket or
portability abstraction. They already use the same libc and that doesn't help
you much either.

> Another thing you could do is do a select() on all of them at once to see if
> any of them are ready to talk. As it is now, different socket types
> (typically) each have their own select() that are incompatible.

Yeah those things are really terrible (and was one of the reasons why I once
upon the time didn't go with libssh). I claim good network-related libs
provide access to the sockets in a way so that you can select() on them.

> In my initial tests of libssh2 it wasn't long before I found myself stuck in
> _libssh2_wait_socket (I think that's the name) without a timeout (it
> *almost* implemented a timeout! :) So probably nothing is perfect.

Did you really use it non-blocking then? That function is used internally in
the lib for waiting for socket actions and that implies blocking. But yes,
when using libssh2 in a blocking mode we don't really have many ways to
configure timeouts (yet).

Received on 2010-01-23