Oleg:
Hello! Good questions, let me dive in:
> >1. You do not need a new account every time your IP address
> >changes. The Gnutella client in the Kaboodle application
> >is meant specifically to address this. That is, the
> >application uses Gnutella to search for the partnership
> >file. When it finds it, it uses the IP address from the
> >machine on which is was found.
>
> The ip addresses of the two partners are written down in the
> partnership file downloaded from the EchoFree server and
> installed at both computers by the helper application.
> Now, let us assume that my ip has been changed. If my partner
> reads my ip from the partnership file stored on his machine, he
> will get the wrong ip. If he gets it from the Gnutella's reply, as
> you said, and ignores the ip value in the file, then I am afraid I
> can not realize why keep the ip addresses in the partnership file.
As I recall, that was either for a "backup plan": if you
have the IP address that was once valid, it may still be valid
without having to do a Gnutella search. Also, it may be usable in
the future to help with Gnutella searching. My understanding of
Gnutella is that it uses "host caches" or "reflectors" to help
client gets started searching. We may be able to use the IP address
in the Partnership file to help with the choice of which hosts
to initiate with.
In short...the IP address in the partnership file shouldn't
currently be used for anything.
This reminds me: we should check to see if the Kaboodle
specific "Gnutella handshake" works with the publicly available
Gnutella host cache servers, such as the ones at gnutellanet.com.
That is, a Gnutella client can use a custom "Connect String" to
create a private Gnutella sub-network within the larger one. It
makes sense for Kaboodle to take advantage of that, if nothing
else than for the wealth of host-cache's available; right now,
we're running just one at "gnutella.get-engaged.net".
> >2. I am not sure what you mean by the "property dialog".
> >Have you more details?
>
> Well, by "property dialog" I meant the property sheet that you
> get when you right-click a computer icon. I may not have got
> all the necessary components, but so far I cannot observe any
> useful functionality. The specification says:
>
> "Component: a self-contained piece of code that extends the
> functionality of Kaboodle. . A Component could provide
> application-layer functionality (such as a notepad or an ICQ
> chat client. "
>
> After installation, I have only one component named "Jetsend
> Receiver". What is it?
Ah. I call the "property dialog" the ProperyPanel, which
is made up of one or several PropertyTabs. Most of the existing
PropertyTabs ae useless. I think the only functional one is
in the NetworkIcon, and is used to initiate the VPN part.
You should feel free to disable any PropetyTab that
doesn't have any apparent functionality. This reminds me that
I need to add to my "to do list" and addition where in every
device's PropetyPanel is a radio button that says "allow remote
Kaboodle users to change this device's settings".
As for JetSend, it's an obsolete piece of technology
that HewlettPackard was very excited about once. It allows for
driver-less printing, so that if you and I were running Kaboodle,
I could VPN with you and print to your printer, without having
to install a driver for it. It should still work, in fact. For
the release we're working on now, though, I'd disable all of
this capability (I think it's called "echoPrint") and disable
anything having to do with JetSend. We'll put something like it
back in if it ever becomes an important feature.
> The component tab has the buttons "Start" and "Stop", which
> you might think swap the state of the component. However, a
> static view of the code shows that they do not really change
> anything but the label on screen. Suppose, I install a
> component named "chat.dll". Will I be then enabled for a chat
> activity? How will I get access to the chat application?
I am not sure of the API details that "chat.dll"
would use. However, I believe the VPN piece is built using
such an approach. I would model future components in a similar
manner.
My understanding is that the "business logic" of
these plugins was fairly well developed in the app.
> >3. I am sorry, I did not mean to use raise the "Warning Level"
> >of VC++, I meant to go to Microsoft.com and download the
> >latest Service Pack update for VC++ 6.0. Then you will
> >be able to compile what's on the CVS server.
>
> I have been able to compile the code since I followed your
> advice and installed Service Pack update. That is all right. I
> just decided to put it to test, which showed that there were
> many potential errors.
Good, glad it's working. It also sounds like you've
found some important potential errors. How do I increase the
"warning level" when I compile?
> Now, as for encryption. There is a class CEncryptor, which has
> the method EncryptDecrypt as well as the two methods
> BlowFishDecrypt and BlowFishEncrypt. The first one is used
> widely through out the code but always with the default key.
> Am I right that BlowFishDecrypt and BlowFishEncrypt are only
> applied when communicating remotely (over the internet) and
> EncryptDecrypt being a lighter encryption provider is applied
> to the intranet traffic (within the LAN)? And does it make
> sense encrypting the intranet traffic on a constant key at all?
Yes, the Blowfish pieces are meant for all remote
communications. I didn't know that intra-LAN traffic was
encrypted with a default key. Huh. If it's not adding much
latency, I see no harm in leaving it. Perhaps we'll implement
a more useful Diffie-Hellman key-exchange in the future so
that the default key isn't needed.
> Now, the main point. I maintained two sockets: one for
> Kaboodle to VNC connection and one temporary socket for
> Kaboodle to Kaboodle connection. The second socket will
> be substituted by the native Kaboodle's steel tube later on. I
> also created a new tab on the property sheet to control the
> VNC connection and view the debug output. With a special
> button, I can start the VNS listener at one side and a VNC
> viewer at the other and establish the three connections:
>
> VNC viewer - Kaboodle Server - Kaboodle Client -
> VNC listener.
>
> I am getting them work together.
Sounds good! Definitely on the right track. Kaboodle
can talk to Kaboodle now using the existing Blowfish VPN piece
it has, and we'll replace that with the OpenSSL steel-tube in
the future. The key is to get a port open on the Kaboodle server
to listen for the viewer's traffic, and then tunnel that data
through to the listener so that it appears to be coming from
the Kaboodle client. Good luck!
So you know, the "VNC listener" is usually called the
"VNC server" and it is typically running as a active service
already. It'd be very interesting, though, if Kaboodle itself
could activate the service if it discovered it is not. Things
brings up the question of what other things to put in the VNC
PropertyTab you've created. By using buttons in this PropertyTab
to affect the registry settings of the VNC server, you can make
it do some pretty interesting things, such as "accept VNC
connections only from other Kaboodle users" or "prompt me for
permission before allowing a VNC connection to connect".
Hope things keep progressing for you!
-Scott
_______________________________________________
Kaboodle-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/kaboodle-devel
