> I think this would be a really nice feature. To implement this without > changes to the VNC server or viewer, I think the dispatcher would have to act > as a VNC proxy. 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 ? :)
> That is, it would have to implement the RFB protocol and act > as both a client and a server. The viewer would first connect to the > dispatcher, and when the user is authenticated and has chosen a session the > dispatcher would connect to the VNC server and act as a viewer. Unless it's > possible to somehow make a direct connection between two open sockets, all > the traffic would then have to pass through the dispatcher. IMHO the "passthru" of the traffic would give unnecessary overhead and performance loss. I think it should be some sort of redirection - i.e. the viewer needs additional "intelligence". > Maybe it could be done by modifying the protocol so that authentication could > be done with both username and password, and so that the server could tell > the viewer to connect to another server. The viewer would then first Yes - something like that. > authenticate itself to the dispatcher - which would be a special VNC server - > and remember the username and the password. After letting the user choose a > session, the dispatcher would tell the viewer to connect to the server with > that session. The viewer would connect to the specified server and go through > the authentication again with the same username and password. I think this > would be the easiest way to do it, but changes to the protocol might not be > very popular. enhancing vnc with this feature will make more people happy, rather than changing the protocol will make people unhappy :) > 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. Only the X half would then keep running between connections. > The dispatcher would be integrated in the RFB half. One instance of the RFB > half would keep running to act as the dispatcher (possibly with an X half > connected to help viewing a session choosing window), and after > authentication and session choosing would fork off a child process, which > would either connect to a running X half or spawn a new one. This would be > compatible with existing viewers, but I have no idea how easily the server > could be split. mhhh - can`t follow very well here - what is the advantage of doing so? just compatibility purpose? this would add another communication layer, and this will make things more complicated and slow things down, IMHO. For an enhanced vnc, an enhanced Xvnc and enhanced vncviewers - at least for linux and for windows would be the way to go, I think. thanks for your quick&long reply ! regards roland _______________________________________________ VNC-List mailing list [EMAIL PROTECTED] http://www.realvnc.com/mailman/listinfo/vnc-list
