That 1-port-per display issue is one of the things that struck me as particularly inelegant when I first encountered VNC; without knowing anything about the technical details behind it, I am guessing that it was motivated by some shortcut taken to simplify the original implementation. Going one step further, it might be nice if the next generation could also respond to HTTP queries on the same port by attempting to serve an applet - assuming that would not introduce excessive complexity or security issues into the server side of the connection.
Is that a theoretical possibility? The client currently looks for a plain-text RFB version number being passed to it from the server; I assume something analogous is done by the server when connecting to a listen-only viewer. Since HTTP connections already do text requests, a plain connection attempt or one with a query keyword appended would seem to me to be able to communicate sufficient information for the server to decide what to do. ----- Original Message ----- From: "Michael Ossmann" <[EMAIL PROTECTED]> To: <[EMAIL PROTECTED]> Sent: Wednesday, 2002-03-20 11:51 Subject: Re: The Next Generation display numbers : On Wed, Mar 20, 2002 at 10:38:40AM -0500, Grant McDorman wrote: : > : > The problem is that VNC, on *nix systems, will always use a display : > number for access by applications. If one drops the display number for : > the VNC client connections, then we'll have *two* unrelated IDs for : > the VNC server - the display number, and the VNC ID, whatever that : > might be (port perhaps?). : : We already have that. A typical Xvnc listens for X apps on :1 and also : listens for VNC clients on :1, where :1 and :1 are two completely : different things. :-/ : : It's even possible, though rare, to have Xvnc use completely different : display numbers for X and RFB, which could be incredibly confusing to : someone who doesn't understand the difference between :1 and :1. And : the system breaks down completely if you have 100+ displays. : : It would be a lot less confusing if all VNC implementations used a : single port for RFB. Xvnc would still have an X display number, but : anyone using X can be expected to figure that out. : : The current system only makes good sense on one platform, and it doesn't : scale. : : > I agree it doesn't make much sense in the Windows-only world; however, : > when connecting to *nix systems (from any system) it does make sense, : > and (in my opinion) should not be removed. : : In a VNC implementation with a single port serving multiple displays, : each display would still need some kind of identifier, and it would make : sense for Xvnc to continue to use the X display number for that purpose. : It would even work with display numbers > 99, which would be refreshing. : : > Perhaps what we need is a way to explicitly specify the VNC port (the : > 580x/590x) on both the client and server. Connections to non-*nix : > systems could then use that. : : That would be nice too. Xvnc currently has command line options with : which you can specify either port number or display number. It would be : nice if other implementations had that feature as well. : : -- : Mike Ossmann, Tarantella/UNIX Engineer/Instructor : Alternative Technology, Inc. http://www.alttech.com/ : --------------------------------------------------------------------- : To unsubscribe, mail [EMAIL PROTECTED] with the line: : 'unsubscribe vnc-list' in the message BODY : See also: http://www.uk.research.att.com/vnc/intouch.html : --------------------------------------------------------------------- --------------------------------------------------------------------- To unsubscribe, mail [EMAIL PROTECTED] with the line: 'unsubscribe vnc-list' in the message BODY See also: http://www.uk.research.att.com/vnc/intouch.html ---------------------------------------------------------------------
