On Mon, 14 Feb 2011 14:07:17 -0600, DRC wrote:
> On 2/14/11 5:42
AM, Adam Tkac wrote:
>>> I see a couple problems with this solution:
>>>
>>> 1. This method still closes the socket after identifying a
port,
>>> which would allow the port to be allocated again before
>>>
/usr/bin/ssh finally gets around to opening the forwarding channel
>>>
and binding to the local port. A second vncviewer process started
>>> in
close proximity is admittedly *less* likely to choose that same
>>>
port, but the possibility still exists. The likelihood would be a
>>>
function of how the operating system assigns ephemeral ports,
>>> which
is certainly platform dependent and hard to predict.
>>> 2. The port
number you'll end up with is an ephemeral port. Although
>>> explicitly
binding to and listening on an ephemeral port is
>>> certainly allowed
by ssh, it is also a little unconventional.
>>
>> DRC's patch seems
like better approach for me than integration with
>> libssh.
>>
>>
However I would extend the patch a little. After we successfully
bind(3)
>> a socket then we can spawn /usr/bin/ssh. We can probably use
exec*(3)
>> instead of system(3) call and check if ssh was able to bind
the port.
>>
>> If not then we can try to find another free port &
spawn ssh again.
>> For example 20 times by default. It's right in
theory SSH tunnel
>> estabilishment might still fail but in practise it
won't happen.
>>
>> What is your opinion about this proposal?
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?
> I've been
using the scheme represented in the patch quite successfully
> with
VirtualGL for years. In VirtualGL's case, the free port has to be
>
obtained on the server side, not the client side, so there is much
more
> risk of conflict, but none has ever been reported.
>
> I don't
understand how, even in theory, establishing the SSH tunnel
> would fail
unless you were trying to launch thousands of vncviewer
> processes at
once (and there are likely to be other failures with that.)
> Each time
you bind the port, the ephemeral port counter is incremented
> by 1, so
even if another vncviewer process tries to bind a port between
> the
time the first process bound its port and launched ssh, then it
> would
still succeed.
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...
Keep it simple. Fix and test the problem at hand. If we go
off trying
to solve theoretical problems that don't yet exist, we may
end up ve 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 tu
tability
('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.
------------------------------------------------------------------------------
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 th
>
="http://p.sf.net/sfu/intel-dev2devfeb";>http://p.sf.net/sfu/intel-dev2devfeb
>
_______________________________________________
> Tigervnc-devel
mailing list
> Tigervnc-devel@lists.sourceforge.net [1]
>
https://lists.sourceforge.net/lists/listinfo/tigervnc-devel
[2]
Links:
------
[1] mailto:Tigervnc-devel@lists.sourceforge.net
[2]
https://lists.sourceforge.net/lists/listinfo/tigervnc-devel
------------------------------------------------------------------------------
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
