> NSPR has no SSL support, that comes with NSS that is built
> upon NSPR (iirc). I don't get what benefits libssh2 on NSPR
> would bring. Can you elaborate?
I'm looking for a common denominator that can be re-used. Yes NSS is built on top of NSPR.
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. When evaluating any socket library, I have to consider all the behavior. Now I'm speaking generically here and not about any particular library:
- does it offer timeouts on its functions, including on connect
- can it be used as both blocking and non-blocking
- test every possible way that it can be disconnected from its remote side. Can it always detect the dropped connection without hanging? In the case of something like SSL or SSH you have to consider that the other side may stop responding at any stage of the process including negotiation and shutdown. Do I have a way to timeout from that?
- What kind of options does it support?
- How does it interact with the signal handling?
- Is it thread-safe? How do I use it in a multi-threaded situation?
- How fast is it?
- Does it leak memory or otherwise consume system resources? What if it runs continuously for a year?
- Will it be portable if I have to move it to another OS? Linux? BSD? Windows?
- Retest everything whenever the version is upgraded
Now assume I have an app that wants to be able to speak in all 3 flavors (plain, SSL, SSH). That means everything in the above list I have to do x3 and re-testing when it's upgraded x3. If they can all be built on a common building block it's less maintenance, and less code overall.
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.
> libssh2 is an SSH library, I don't think it should become
> "the ultimate socket library" nor should it do SSL.
I wasn't saying to put SSL in libssh. I was saying I would build my own library or app which uses NSPR for plain sockets, NSPR+NSS for SSL and NSPR+libssh2 for SSH.
Anyway, that's what I was thinking; that's the end of my effort to explain it.
In fairness to libssh, I have been using it for 2.5 years and the blocking issues I have don't happen very often, even using an old version. I sort of fell off the wagon when it switched to cmake, don't remember offhand what the issue was.
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.
At the end of the day, I am responsible for providing something to others that I have to be able to prove will behave a certain way. So I have to know how everything I depend on will behave.
_______________________________________________
libssh2-devel http://cool.haxx.se/cgi-bin/mailman/listinfo/libssh2-devel
Received on 2010-01-23