Hello, I have spent some thoughts of session management in vnc (also
loadbalancing)
and would like to present a little conecpt, which would need just little
change to
existing vnc (and no change to protocol at all)
[1] = vncviewer Wrapper (reference implementation perl, later C, included
inside
vncviewer)
[2] = Xvnc Dispatcher/Wrapper (perl)
1. [2] is running on 5800/tcp and waiting for incoming connections from [1]
2. [1] requests login/password & connection data
(host[/farm],geometry,colordepth)
from user
3. [1] ---- 5800/tcp ---> [2] - username/password/geometry/colordepth is
transmitted
4. [2] checks auth.
5. If auth ok:
- If no previous session from user exists, spawn Xnvc under corresponding
useraccount
(login) and with passed parameters on next free tcp port on host with
most "free
ressources". Loadbalancing will have to be implemented, could be
round-robin in the
first implementation. Store session information "somewhere". [2] would
need to have
to communicate with other instances on other hosts to exchange session
information and
to know about the "load state" of the hosts.
- If previous session for that user exists (read Xvnc host/port for that
user from
"somewhere") and go to 5.
6. Report hostname and portnumber of running Xnvc to [1]
7. [1] spawns vncviewer and passes hostname, portnumber and password
8. vncviewer connects - the user gets a new session or gets back his old
session
problems:
- Existing vncviewer does not take password via commandline (could be fixed
easily)
- Xvnc authentication is via separate password, but we need
username/password authentication to
do the session management. Unix password and vnc password should be
unique.
- how to differ between "disconnect" and "terminate" a vnc session ?
what do you think. Could this be a "way to go" ?
comments/questions are highly welcome.
regards
roland
----- Original Message -----
From: "Bjvrn Persson" <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>
Sent: Sunday, March 23, 2003 2:13 AM
Subject: Re: session management in vnc like in citrix or sunray ?
> Roland wrote:
> > I see now problem changing server, viewer or protocol. Welcome to
> > OpenSource :)
> >
> > Shure, we should not break existing functionality - but if we add
> > "enhancements" as an option ? :)
>
> The first thing the server and viewer do is to agree on the protocol
version,
> so it's certainly possible to add extensions without breaking existing
> programs. If the RealVNC staff don't like your ideas you can always start
> your own branch. There seems to be a lot of those already. Welcome to Open
> Source! :-D
>
> Ah yes, you said you are a bad programmer. That could be a problem...
>
> > > Another way would be to split the server in two halves - the RFB
server
> > > end and the X server end - and let them communicate in some way,
> > > probably by shared memory.
> >
> > mhhh - can`t follow very well here - what is the advantage of doing so?
> > just compatibility purpose?
>
> Compatibility and the VNC philosophy of having the complexity in the
server
> and keeping the clients very simple. And it should be faster than the
proxy
> approach.
>
> > this would add another communication layer, and this will make
> > things more complicated and slow things down, IMHO.
>
> Yes, it's more complicated that way, but shared memory should be fast and
I
> don't think the slowdown would be noticeable.
>
> I think I like the method with an enhanced protocol better though.
>
> Bjvrn Persson
> ("Bjvrn", eh? Hmmpf! I think a certain list server needs to get its MIME
> support fixed.)
> _______________________________________________
> VNC-List mailing list
> [EMAIL PROTECTED]
> http://www.realvnc.com/mailman/listinfo/vnc-list
_______________________________________________
VNC-List mailing list
[EMAIL PROTECTED]
http://www.realvnc.com/mailman/listinfo/vnc-list
