On 2/14/11 4:02 PM, Eric Stadtherr wrote:
> Do you know of a way to check for the successful bind? One of the
> behaviors that drove me down the libssh path was that /usr/bin/ssh
> happily continues running despite failing to bind to the local port.
> Therefore there is no exit status to interrogate for success/failure.
> Can you think of a different way to check for successful bind?
If it's not returning a failure status, then I'm not sure how it could
be done.
> You're making an assumption about how the operating system assigns
> ephemeral ports (the +1 counter). There isn't any specification (at
> least that I'm aware of) that dictates how this assignment should work,
> or even what range of ports should be used. I have witnessed different
> behavior on different operating systems. Like I said earlier, you're
> certainly greatly reducing the likelihood of a conflict, but not truly
> addressing the issue. As soon as you close the bound socket, you're
> releasing the port number back into the wild and opening up the
> possibility of conflict. In my experience, the 1% error case always
> bites you the first day you deploy to a mission-critical system...
I've been successfully using this type of port finding mechanism for
years with VirtualGL. It works solidly on Linux, Solaris, and Windows,
at least. The round robin ephemeral port assignment may not be part of
the spec, but it is the de facto behavior of modern operating systems.
I'd be curious to know what O/S's you're referring to that don't behave
in this way. I also don't understand why you can't thoroughly test it
on your specific configurations rather than argue a purely theoretical
case against it. You seem to have not even bothered to test the code
and see if it addresses the problem.
Even from a theoretical point of view, if we know that the operating
systems you plan to deploy on use round robin ephemeral port assignment,
can you conceive of any failure mode in that case? I can't.
> I agree that libssh does more than solve the immediate port problem, but
> I was also trying to be proactive about other things, namely performance
> (eliminating another process and another socket connection when using an
> SSH tunnel) and portability ('system("/usr/bin/ssh -blah -blah -blah
> sleep 20")' isn't a portable tunnel implementation).
>
> If the license of libssh is not compatible, then that's certainly a
> tangible argument against the integration. libssh is delivered with both
> an LGPL and BSD licenses, though, which I thought were at least as open
> as TigerVNC's GPL license.
You're misunderstanding. The issues were:
(1) I was concerned that libssh would not perform well if it had to rely
on GnuTLS (I am still unable to get decent performance with GnuTLS,
although Martin is unable to reproduce my issues. We need to nail down
what's going on there)
(2) OpenSSL has a GPL-incompatible license, and OpenSSL would have to be
used if GnuTLS didn't perform well.
------------------------------------------------------------------------------
The ultimate all-in-one performance toolkit: Intel(R) Parallel Studio XE:
Pinpoint memory and threading errors before they happen.
Find and fix more than 250 security defects in the development cycle.
Locate bottlenecks in serial and parallel code that limit performance.
http://p.sf.net/sfu/intel-dev2devfeb
_______________________________________________
Tigervnc-devel mailing list
Tigervnc-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/tigervnc-devel
