Wed Aug 28 08:51:01 2002
> -----Original Message-----
> From: Justin Spears [mailto:email@example.com]
> The first thing would be a true default port, my thought is vnc would
> always listen on current default 5900 and when a user
> connects a list of
> current sessions running would be displayed, that they may or
> may not be
> able to connect depending on the password that was entered,
> or have the
> option to create a new session. This would be very
> helpful in UNIX world where their may be many separate
> desktops running
> at the same time and user may (or may not) know what port will connect
> them to their desktop. In addition there is always the
> chance that when
> their Xvnc server dies that another user may take over their port,
> causing a state of user confusion. I do not think this would
> require any
> changes to the client, because the chooser would actually be server
> side. This would take place right after the connection to the server
> was made.
I've been browsing trough a system like
http://www.sourcecodecorner.com/articles/vnc/linux.asp. I find the rfb
communication is just on any other port. Since the used port is below 5900,
I have a verry hard time to recalculate the portnumber. I'm on a W2K viewer
machine. How do I calculate a display number?
I've twiggled the -once and -shared options too but somehow I missed an
option. I think it can also be some security on the inet or xinet side, not
allowing other connections to the used port, I'm still investigating.
btw, I use `netstat -a` on the vncserver machine to see what port is
actually used. Has someone a better idea?
> It could be even further enhanced to add true multi-user
> (that the correct session is selected based upon the username), though
> that would mean modifying the servers + clients.
That's verry hard for a server, specially if it is in -broadcast since that
uses an account on an other machine.
For a viewer, there should be no difference for a start: it's the user that
needs to know the actually used display or port number.
For the server side, I'm thinking of setting up a webserver with a
(cgi-driven) page that shows actual sessions. Since the java viewer starts
with a portnumber, there is no recalculation necessary.
> Doh! authentication is the first thing client expects (well that and a
> few setup variables such as color maps, and window size, rfb version.
> Perhaps the server can cache the authentication the client
> sends and try
> that password when the user selects an existing session (or selects a
> new session), then pass that password when the session is selected.
Since there is no security on the Xvnc side, best to start a password
enabled screensaver. Then at least the session has some protection based on
the unix account.
Future implementations of Xvnc can activate the screensaver on a
> Which brings me to the second "Enhancement". Fixing the authentication
> method so the client does not have to start from scratch every time
> it fails but allow retries until max failure is reached (which the
> server *sorta does*). But this would require clients that handled
> authentication differently and might a LOT more work...
> Any thoughts, or if something like this has been implemented or would
> like to help implement this, please lemme know.
Try setting up a inet connection and open an other connection to the same
- What options are needed for Xvnc to allow multiple connections to a -init
- What security must be disabled to allow other connections to the same
- How to find the actual used port for the rfb communication.
- create a cgi-script to display the available connections.