Igor:
Hello! Some good stuff in your email. I have some
replies in line:
> It seems to me that now I understand what Kaboodle's VNC Server
> functionality you want.
> Earlier I have upset by phrase of the check box "*Use* Kaboodle to
> startup VNC Server *only* when it's needed".
> I could not to understand what means the word *only* in this phrase.
> (It seems to me that it will be good to say "Allow Kaboodle to startup
> VNC Server when it's needed".
> Of course, I understand that my american language is not my mother
> language.)
Sorry for the confusion. I think your american english is
very good! I can imagine it must be very difficult to talk in
one language, program in another, and email in a third. :)
> Next version of the algorithm.
> (We will put the text of algorithm in source code after completion of
> revision .)
Good idea!
> I) At the startup, Kaboodle tests if it must work as a tunneling VNC
> server. Also Kaboodle tests "Allow only users from machines in this
> Access List to connect":
> - if there is "Use Kaboodle to startup VNC Server only when it's
> needed" and independent VNC server is not running,
> then Kaboodle will apply "Allow only users..." directly before VNC
> server start,
> - if there is not "Use Kaboodle to startup VNC Server only when it's
> needed" or independent VNC server is running,
> Kaboodle cannot to apply "Allow only users...".
> Kaboodle only show following MessageBox
> (Cannot implement the functionality <Allow only users from machines in
> this Access List to connect>.
> If it needs for you, please do following
> - check <Use Kaboodle to startup VNC Server only when it's needed>,
> - shut down independent VNC server.)
I don't think we need to show this MessageBox. When the
user first activated ""Allow only users..." and hit "Okay", we
show a MessageBox saying "Please restart your VNC Service for
these changes to take effect". We should just rely on the user
doing this. Or, of course, we could have Kaboodle send a restart
signal to the VNC service...but I don't think we know how to do
that.
> II) Kaboodle begins listening to connection on the TCP port number
> "Use This Port for these tunnels" (for "tunneling VNC server"
> possibility). Kaboodle waits until this connection becomes established.
>
> III) Connection has been established.
> Kaboodle checks if independent VNC server is running.
>
> a) If independent VNC server is not running and
> there is not "Use Kaboodle to startup VNC Server only when it's needed",
> then
> - Kaboodle show user MessageBox
> (Independent VNC server is not running.
> You not allow "Use Kaboodle to startup VNC Server only when it's needed".
> The Requirement on VNC session from "IP address" is declined.)
> - Kaboodle send special message to partner and finishing session.
> - Partner Kaboodle show user MessageBox
> (Partner's independent VNC server is not running.
> Partner not allows "Use Kaboodle to startup VNC Server only when it's
> needed".
> Your Requirement on VNC session from "IP address" is declined.)
Lets have the two messages read: "Sorry...ServerName is
not currently running the VNC Service" and "Sorry...ServerName
is not accepting connections from ThisMachineName".
Ideally...if an independent VNC server is not running,
and if Kaboodle is not authorized to start the service when it
needs to, then the information in Kaboodle on the Viewer side
should indicate this. Perhaps we need a "status" column in the
VNC Service Icon? So it could show "active", "automatic" (for
when Kaboodle will start the service), and "off" for each of
the known VNC servers on the network.
> b) If independent VNC server is running,
> then Kaboodle read from VNC server registry in which port VNC server is
> listening.
>
> c) In other case Kaboodle write to VNC server registry next data
> - *AllowLoopback*,
> - *LoopbackOnly* if user has checked "All VNC use must be through a
> Kaboodle tunnel",
> - *AuthHost* if user has checked "Allow only users from machines in
> this Access List to connect",
> - *PortNumber* from field "Run this service on:".
> Kaboodle stores previous values of above registry.
> Then Kaboodle starts a new copy of VNC server.
> If this start failed ( proper value of code of error Kaboodle will get
> through Win system function GetLastError().
> It can be WinVNC.exe file is absent, etc...), then
> Kaboodle show user MessageBox( Failed to start VNC server - text of
> GetLastError() ),
> send special message to partner and finishing session.
> Partner Kaboodle show user MessageBox( Partner could not to start VNC
> server - text of GetLastError()).
Sounds good.
> IV) Kaboodle creates TCP connection with VNC server as
> a) <loopback IP address>, <PORT >,
>
> if that connection failed then Kaboodle creates TCP connection with VNC
> server as
> b) <IP address of the LAN interface>, <PORT >,
> where <PORT >
> - number from VNC server registry if independing VNC server is running
> (see IIIb).
> - number from field "Run this service on:" if Kaboodle starts a new
> copy of VNC server.
>
> If this TCP connection with VNC server have not established, then Kaboodle
> - get proper value of code of error through Win system function
> GetLastError(),
> - show user MessageBox(Failed to connect with VNC server "text of
> GetLastError()" ),
> - send special message to partner and finishing session.
> Partner Kaboodle show user MessageBox(Partner Failed to connect with
> VNC server - "text of GetLastError()").
Good!
> V) Kaboodle does data exchange between these sockets (encrypting,...)
>
> VI) If user changes the settings of PropertyTab "VNC settigs" on the
> server side,
> then Kaboodle prompt the user with
> "The change you have made will take effect after you restart your VNC
> Service".
Lets have it read: "Please restart your VNC Service now to
have these changes take effect."
> Commentary 1. In current version Kaboodle must be restarted after user
> change setting
> "Enable Kaboodle Tunnels for VNC". The reason of this is following.
> All the Kaboodle's partners must know about this change.
> I don't know what the message Kaboodle can send to partners for it.
> It seems to me I will find this message or add a special new message.
I think we'll need to add a special new message. It would
be good if the user didn't have to restart Kaboodle, obviously.
> Commentary 2. After finishing VNC session, Kaboodle restores all VNC
> server registry changes.
Only if Kaboodle auto-started the VNC server, then yes.
And after the VNC session, Kaboodle should just leave the service
running.
Lastly...I think it would be useful for Kaboodle to help
log VNC server usage. So, at the bottom of the PropPanel, a checkbox
can say "Log VNC usage" with a "View Log..." button next to it
that's grayed out if the checkbox is off. If the user selects this
CheckBox, we activate set DebugMode and DebugLevel to 1, and then
show the Winvnc.log file in Notepad when "View Log..." is hit.
Thanks!
-Scott
> ----- Original Message -----
> From: "Scott C. Best" <[EMAIL PROTECTED]>
> To: "Igor Kotelevsky" <[EMAIL PROTECTED]>
> Sent: Wednesday, April 24, 2002 8:12 PM
> Subject: Re: I need some VNC Server Panel's clarifications (Re: VNC panel
> mockups)
>
>
> > Igor:
> > Heya. Some answers inline:
> >
> > > The New algorithm must work approximately as follows.
> > > I) At the startup, Kaboodle tests that
> > > - Kaboodle must work as a tunneling VNC server, and/or
> > > - Kaboodle must apply "Allow only users from machines in this Access
> > > List to connect".
> > > If neither then return.
> > >
> > > a) Kaboodle does NOT test that independent VNC server is running.
> > > b) Kaboodle does NOT prompt "Please shut down your VNC service...".
> > > c) Kaboodle saves in VNC registry the following data
> > > - *AllowLoopback* if user has checked "Enable Kaboodle Tunnels for VNC",
> > > - *LoopbackOnly* if user has checked "All VNC use must be through a
> Kaboodle
> > > tunnel",
> > > - *AuthHost* if user has checked "Allow only users from machines in this
> > > Access List to connect".
> >
> > I think that's right. Although it would be useful to test
> > if the independent VNC server is running and listening to the
> > loopback interface. We'll need to know that when a connection is
> > started. We'll also need to know which service is running so that
> > we know which registry settings to change.
> >
> >
> > > II) Kaboodle begins listening to connection on the TCP port number "Use
> > > This Port for these tunnels" (for "tunneling VNC server" possibility).
> > > Kaboodle waits until this connection becomes established.
> >
> > Yes.
> >
> > > III) Kaboodle checks if independent VNC server is running.
> > > If it is not running then Kaboodle starts a new copy of VNC server.
> >
> > Only if the button #4 is checked, then yes.
> >
> > > IV) Kaboodle creates TCP connection with VNC server as
> > > a) <loopback IP address>,
> > > <port (display) which is in the field "Run this service on:">.
> > >
> > >
> > > If that connection failed then Kaboodle creates TCP connection with VNC
> > > server as
> > > b) <IP address of the LAN interface>,
> > > <port (display) which is in the field "Run this service on:">.
> >
> >
> > If an independent VNC server is running, then <port>
> > should be the one used by that server, which may not be what
> > the user has specified in "Run this service on:".
> >
> >
> > > V) Kaboodle does data exchange between these sockets (encrypting,...)
> > >
> > >
> > > VI) If user changes the settings of PropertyTab "VNC settigs" on the
> server
> > > side,
> > > then Kaboodle
> > > - tries to apply those settings at once and/or
> > > - says "The change you have made will take effect after Kaboodle is
> > > restarted".
> >
> > Hmmm. Why does Kaboodle have to be restarted? It could
> > just make those changes to the registry, and prompt the user
> > with "The change you have made will take effect after you restart
> > your VNC Service".
> >
> >
> > > I am concerned by the following things.
> > >
> > > 1) I do not see where Kaboodle uses parameter
> > > "Use Kaboodle to startup VNC Server only when it's needed".
> > > It seems to me that whether the user checks this box or not - it does
> not
> > > matter for Kaboodle.
> >
> >
> > It should matter, though. For whatever reason, if the
> > user shuts down their VNC service, it'd be *weird* if Kaboodle
> > just started it whenever it needed to, without being given
> > permission to do so. :) Button #4 is important. But keep in
> > mind: most users will be running an independent VNC server.
> > I'd say over 90-percent.
> >
> >
> > > 2) The User has many VNC session parameters to tune on server side.
> > > This is good on one hand.
> > > But on the other hand user can assign the wrong parameters and VNC
> session
> > > will not establish.
> > > It seems that if this occurs, then
> > > - Kaboodle on server side must show detailed MessageBox to user, and
> send
> > > the above data to partner Kaboodle,
> > > - Kaboodle on viewer side must receive this data and show a similar
> > > MessageBox to user.
> >
> > Can you describe an example? I can think of two. First, if
> > Kaboodle fails (for some reason) to start the VNC server. We should
> > tell the user why. If the server's running, Kaboodle will try both
> > the Loopback and the LAN interface...it should always at least get a
> > connection. But the password in the Viewer-side Kaboodle might be
> > wrong. So we'd need to tell the user that somehow.
> >
> >
> > -Scott
> >
> > <old stuff deleted>
> >
> >
>
>
_______________________________________________
Kaboodle-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/kaboodle-devel
