Oleg:
        Hello! A quick comment: it's important that, eventually, all
tunnelling uses the Kaboodle TCP connection, as that connection is
a single TCP port. Part of the point of this tunnelling, after all,
is so that the user need open only one hole in their firewall and
run multiple apps, securely, thru that hole. For now, as things get
started, it's okay for VNC to use its own connection. Before we can
release the product, though, we'll have to fix this.

        Also, AFAIK, as VNC is a TCP based application, it's by
definition *not* sensitive to packet-to-packet gaps. The data
delivered *within* the packet, certainly, is senstive to added or
missing data, but I'm sure that's true of most apps and not just
VNC.

        My thought here is that the channelization of data within
the Kaboodle-to-Kaboodle data packets must be well understood.
Those packets must be able to handle Kaboodle-management related
stuff and an arbitrary number of tunneled data packets. I think
if you look at the source of the OpenSSH or ZeBeDee project,
you'll see some good solutions. Or, of course, perhaps your or
igor's VPN experience will offer a solution. I expect this whole
secure-tunnel to be, ultimately, its own thread within Kaboodle.

-Scott


On Tue, 11 Dec 2001, Lyapin Oleg wrote:

> 11 dec 2001 Status report
> -----------------------------
>
> A new project appeared in Kaboodle's workspace: VNCSession. It is a
> stand-alone exe-application that supports VNC tunneling. This is a next
> temporary solution, which allows for independence upon the Kaboodle internal
> threads and Kaboodle socket implementation:
> 1. VNC is extremely sensitive to gaps in data flow. Kaboodle apparently
> performs periodical network inquiries and screen updates in the main thread,
> which leads to execution delays and thus connection breaks or runtime errors
> in the VNC Viewer. To avoid this, VNC tunneling now uses its own connection
> rather then Kaboodle's native tube.
> 2. As it was discussed in the previous report, we use CSocket MFC class for
> both VNC-Kaboodle and Kaboodle-Kaboodle communications while Kaboodle uses
> CAsyncSocket MFC class for all connections. The idea of total retrofitting
> Kaboodle's sockets, I am afraid, must wait until later (may be when we
> implement SSL/SSH).
>
> At present the user interface looks like this. You right-click _your_
> computer and choose the VNC tab on the property panel. Then you click the
> "Listen:" button to start VNC server. You will get the VNCSession window.
> (It is a temporary solution and will definitely be eliminated in the release
> version). You must click the "Listen" button.
> At the other computer, you right-click the server that you have just
> launched and also go to the VNC tab. Then you click "Start Sessoin" and in
> the VNCSession window click "View". The session begins.
>
> The VNC operation is only stable until you open or close a window thus
> forcing a large region to be updated. Here you have a problem: the server
> unexpectedly closes connection. We believe it is due to a gap during data
> transfer.
>
> The registry keys values AllowLoopback and LoopbackOnly appeared really
> useful. We set them as follows: AllowLoopback = 1, LoopbackOnly = 0 - this
> proved to be the only combination that works. The VNCSession application
> reads the old values, stores them in Kaboodle's registry section and sets
> the new values as above. If the application has been aborted or abnormally
> terminated then the next time it runs the saved values are picked up, which
> guaranties the original settings are not lost. On exit, the saved values are
> restored.
>
> -Oleg
>



_______________________________________________
Kaboodle-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/kaboodle-devel

Reply via email to