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?
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. 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 creating new real problems. ------------------------------------------------------------------------------ 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
