On 2/11/11 9:16 PM, Eric Stadtherr 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.
Before I posted the patch, I tested it, and it works fine for me. I suspect it will work for you as well, if you would take a minute to try it. When you bind to port 0, as the new code does, the system chooses a free port and then increments a counter, so the next bind to port 0 will come up with the next port in sequence. Thus, you would have to launch thousands of VNC Viewers before you would run the risk of a port conflict (it would have to reach the end of the ephemeral port range and cycle back around again.) Regarding point (2), we're hardly the only ones doing this. > Understood. Although I still think that libssh would get us one step > closer to Windows tunneling support than the existing system() call > method. libssh keeps vncviewer from having to encode the > platform-specific semantics of child process invocation and management. libssh is a non-starter unless we can use it with OpenSSL, which I'm given to understand we can't. Thus, we need to figure out the initial problem, which is how to avoid a port conflict. ------------------------------------------------------------------------------ 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
