Miss Shoba:
Okay...here's a different idea. Have a look at the
ZeBeDee utility:
http://www.winton.org.uk/zebedee/
It's being released now not just as source code but
as a standalone Windows binary. Hmmm!
Have a look at the manual page. You can start ZeBeDee
on one side of the connection as a service. You start the other
side as a client, and connect. Suppose our server is running
on "1.2.3.4". We've already connected to each other using
conventional Kaboodle VPN'ing (ie, simple messages can be
exchanged, but no tunneled data). Using that channel, we have
enough control to signal the start of a ZeBeDee service if a
tunnel is needed for anything.
So we start that service on the server with just
"zebedee -s". That opens a TCP port listener on TCP 11965 (we
can set it to any port we need to, of course). On the client,
"zebedee 1.2.3.4 abc:1.2.3.5:5900 connects to our service,
tunneling data to from localhost port abc to 1.2.3.5's port
5900.
Isn't this EXACTLY what we want Kaboodle's to do, at
least for the initial release? Can you think of a reason we
shouldn't simply include the ZeBeDee binary with the Kaboodle
installer (just like we're using the winpcap dll) and use that
functionality, rather that write our own system from scratch?
-Scott
On Wed, 3 Jul 2002, Scott C. Best wrote:
> Miss Shoba:
>
> Okay, I think I understand. Currently, Kaboodle is built
> so that it can administer a VNC connection to any VNC server that's
> *on the same LAN* as the PC running Kaboodle. We need to extend
> that so that it can administer a connection to any VNC server on
> any of the Engaged LAN's as well.
>
> How should we do that? We need a way for Kaboodle to
> automatically recognize that it needs to activate a connection via
> your tunneling code (which acts as a "secure proxy" service) rather
> than a direct connection. Also, it needs to know which machine
> is the "master gateway" or "VPN node" for the LAN. So if I setup
> a VPN from PC1 of LAN1 to PC3 of LAN2, I can then startup VNC on
> PC2 of LAN1 and connect to PC4 of LAN2 without having to
> explicitly tell Kaboodle that PC1 and PC3 are gatewaying the
> connection. Tricky stuff.
>
> I think looking at the NID is the right place to start.
> If a connection is being initiated from PC1 on LAN1, it looks
> at the LAN membership of the target machine. If it's on the same
> LAN, it can connect directly. If it is not on the same LAN, it
> instead makes a call to your tunneling code (e.g., "this is PC1
> of LAN1 looking to make a VNC connection to PC4 on LAN2"). The
> response from the tunneling service should be "ready for data
> on 192.168.1.4 port xyz" where the .4 machine is the VPN gateway
> PC. The first part of this (ie, determining whether to connect
> to a machine or to the proxy) should be a fairly straightforward
> modification of the existing VNC management code.
>
> Please let me know what you think. I am CC'ing the other
> developers so that they know what's going to change. They may
> even be able to indicate exactly where the changes should be
> inserted.
>
> -Scott
>
> PS: I still really do need to know the latency numbers for your
> proxying service. It's critical that they be as low as
> possible, and I don't think using MFC sockets will work.
>
>
> On Mon, 1 Jul 2002, shoba wrote:
>
> > Dear Scott,
> >
> > Pleaae see the attachment for the debuging status of the project.
> >
> > Let us know your comments.
> >
> > Regards,
> >
> > Shoba
> >
> >
> >
> >
> >
> >
>
>
>
>
-------------------------------------------------------
This sf.net email is sponsored by:ThinkGeek
Caffeinated soap. No kidding.
http://thinkgeek.com/sf
_______________________________________________
Kaboodle-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/kaboodle-devel
