Igor:
Hello! Hope you're feeling better. Some quick replies,
then a longer idea:
> >The WinNT Kaboodle
> >activates the VNC server, checks the password, and reports
> >back that it's wrong. However...it doesn't then *stop* the
> >server.
> You are right. Even in case the password is incorrect the service
> must be stopped. I have fixed that already.
I hope your CVS access is up soon so I can test your
fix. If you want to just email me the files that changed, I
can push them into my snapshot.
> >If I go to the WinNT machine and manually
> >shut down the VNC server (the icon is active, so the server
> >is connected to something),
> To the Win98, I think
> >a message appears on the Win98
> >box saying something like "Partner Kaboodle has shut down
> >VNC".
> Is there something wrong about it?
Only problem is that I get this message after I shutdown
the VNC server which should have shutdown by itself (it stayed up
when I gave it the wrong password). If the server is "auto-shutdown"
then I shouldn't get this message. But don't worry about this;
see below.
> I continue debugging the multy LAN messaging. I have some problems with
> my LAN connection so I have no access to CVS. Sys admin promised to make
> connection on Monday.
> When I merged the new piece of code with LAN detection I found that they
> bound to machine name, which may change. I suggest binding to MAK address.
Yes, binding to MAC address makes more sense.
Okay, now for the longer idea. I think the idea of Kaboodle
starting up the VNC server, if it needs to be, is a good idea. But
I think Kaboodle should be smarter about VNC servers that are already
active. After all, if the server is active and Kaboodle is active,
Kaboodle *should* be able to tunnel a VNC connection.
So here's what I suggest. We should change the functionality
of that first button in the VNC Server. Right now it says "use
Kaboodle to control startup of the VNC server". We should change
that instead to say "all VNC connections must be tunneled through
Kaboodle".
So if the user selects that first button and clicks "Okay",
we check the "LoopbackOnly" registry entry for VNC. If it's set to
"1", then we're done. If it's set to "0", we change it to a "1" and
then prompt the user to shutdown their VNC server: "You need to
shutdown your VNC server for this change to take effect. Kaboodle will
start up the server automatically when needed.". It'd be nice if
Kaboodle could force this shutdown, but I can live without that. Of
course, if the user unchecks this button and clicks "Okay", if the
registry entry is set to a 1, it should be set back to 0, and the
user prompted with: "Please restart your VNC server for this change
to take effect."
When this 1st button is selected, and another Kaboodle user
initiates a VNC connection, the Kaboodle instance on the VNC server
side must do 3 things. First, it checks to see if the "Allow List"
button is selected. If it is, it checks to see that the initiating
Kaboodle user is connection from an allowed machine. Second, Kaboodle
checks to see if the VNC server is running. If it isn't, Kaboodle
needs to start it up. Third, Kaboodle tunnels the connection very
much like it does now. We might want to get tricky here and try to
use 127.0.0.1, and if that fails (because the user failed to restart
their server) we could try the IP address of the LAN interface.
When Kaboodle is done tunneling the VNC session, it can just leave
the server running. No one would really mind that.
I think this is more elegant. Kaboodle now only needs to
worry about starting up the service, not shutting it down. And if
a user "mistakingly" starts up the VNC service outside of Kaboodle,
it'll still work.
Thoughts?
-Scott
_______________________________________________
Kaboodle-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/kaboodle-devel
