Oleg:
Some quick questions for you:
1. What TCP port are you using for Kaboodle->Kaboodle for
secured VNC traffic?
2. How many sessions of VNC can simultaneously be carried
across this channel? I'm *really* hoping it's more than
just one...
3. I'd be interested in hearing your figures for redesigning
the "steel tube" interface. Long term, it *must* work that
all traffic between two remote Kaboodle users is transacted
over a single TCP stream. It must carry Kaboodle "control"
info, VNC data, and be scalable to support an arbitrary
number of other bidirectional data "channels".
4. I've done some work already specifying two key-exchange
solutions. They both still uses Gnutella for partner discovery,
but have different mechanisms for creating the partnership
certificates.
cheers,
Scott
On Thu, 20 Dec 2001, Lyapin Oleg wrote:
> 20 dec 2001 Status report
> -----------------------------
>
> Let us summarize what has been done and our plans for the future.
>
> I. PRESENT STATE
>
> The problem with slowing down, described in the previous report,
> has been solved.
>
> At present, we have:
>
> 1. The VNC traffic is being forwarded through a special connection
> between two Kaboodle machines.
> 2. This connection is not the one Kaboodle has been using to its
> own purposes and consequently the TCP port is different.
> 3. When forwarding the VNC traffic, encryption is applied using
> the methods and the keys that Kaboodle has been using.
> 4. The tunneled VNC session is quite stable (no connection breaks)
> and rather fast acting (just slightly slower than pure VNC
> session).
>
> II. IMMEDIATE TASKS
>
> Here is a little bug. When the Kaboodle+VNC to Kaboodle+VNC
> connection closes, the TCP port is not released. So next time the
> connection is established, it must use a different port.
>
> By the end of the year 2001 the following is to be done:
>
> 1. Fix the abovementioned bug.
> 2. In order to do it, as well as to make the code compact,
> Kaboodle+VNC to Kaboodle+VNC MFC-based socket must be redesigned
> like Kaboodle to VNC WinAPI-socket.
>
> III. LONG-TERM PLANS
>
> We can suggest the following direction of Kaboodle+VNC development:
>
> 1. Completion of the user interface.
> 2. Launching the VNC Server at Kaboodle start.
> 3. Retrofitting to the steel tube. It implies one of the two options
> (variants 3A and 3B are mutually exclusive):
> A. Update the implementation of Kaboodle CSocketTCPIP class so as to
> (a) retain the support of Remote Connection functionality and (b)
> ensure the support of intensive bilateral data streams required by
> VNC tunneling (see the previous report for detail). The encryption
> and key exchange solution are left unchanged.
> B. Implementation of SSL/SSH tunneling including socket, encryption
> and key exchange solutions.
>
> TIMING
>
> Variant 3A: about 2.5-3 months;
> Variant 3B: we need another 2 weeks to estimate timing.
_______________________________________________
Kaboodle-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/kaboodle-devel
