Imran:
        Hello! Some answers for you:

> Hello! I got the code and compiled it and got the VPN
> to run. I used the instructions I sent and it seemed to work.
> I used a LAN on one connection and a AOL dialup on another.
>
>  This sounds good that you had compiled our code at your end sucessfully,
>  please send us the feedback for our maodule after testing at your end.
>  as all of our team members are waiting for your feedback for the code.

        I did not try VNC'ing across the VPN that your code
creates. Can you describe how I should do that?

>   => are you connected to internet directly from both gateway ?
>
> as we don't get what do you mean by "I used a LAN on one connection and
> a AOL dialup on another." please elobrate on this.
> As we had used seprate dailup for both the LAN's
> that is PC2 and PC3 are directly connected to internet through seprate dailups.

        I've one PC that is on a LAN behind a firewall. I port-forward
TCP 4182 and 4183 across the firewall to the PC running Kaboodle. I've
another PC that I connect to the Internet via a dialup ISP (America
Online). I then install Kaboodle on the second PC and register on the
GetEngaged website. I do the same on the LAN PC. After installing the
PartnershipFiles on both machines, I restart Kaboodle, and I can then
VPN from one to the other.
        Please note: the IP addresses in the Partnership file match
the addresses of the two PC's. This is a bug in Kaboodle: it needs
these two to match, else it will not work. I hope to be fixing that
soon...

> Regarding the latency report, I need to know the *latency*
> numbers, not the *data transfer rate*. Those are two completely
> independant quantities.
>
> For instance, if I open a pair of MFC
> socket listeners in Kaboodle, read 1 kB of data on the first and
> then write that same 1kB of data out the second, it takes over
> two seconds for the roundtrip to complete.
>
>  => Here you are assuming that 1 sec to reach data and then decide that
>     it will take 2 sec to complete round trip.

        No, I'm not assuming that it takes 1 second for the data
to reach. The data transfer time takes less than 50 milliseconds.
The problem is what the *MFC socket code* does with the data. It
reads it in, *and holds onto it for more than a second*, before it
allows the data to be written out again. It has nothing to do with
the LAN interface card, it has everything to do with the manner
in which the MFC socket code buffers the data.

>  => in our case how we can calculate this as our communication path is
>  PC1->PC2->PC3->PC4 .
>     If I send 1 kb data from PC1 - PC4 and it return from PC4 - PC1,
> the number of seconds is latency.
>  => But the speed between PC2-PC3 vary then how we can calculate latency ?

        Try it. Write an MFC socket based "echo" service. Run it
on PC1. Send PC1 some data on port X from PC2, have it spit the data
back out at you on port Y of PC2. Call the round-trip time T1. Then
use ping: from an MSDOS command line on PC2, send a ping to PC1.
See how long it takes. Call this T2. Subtract T2 from T1, and what's
left over is how long the MFC socket code held onto your data before
sending it out. From everything I've read about MFC socket classes,
you'll have more than a second of time left over. If I use that sort
of socket class in a VPN, it will make using a remote-control app
like VNC nearly impossible.

        Hope this helps!

-Scott


_______________________________________________________________

Have big pipes? SourceForge.net is looking for download mirrors. We supply
the hardware. You get the recognition. Email Us: [EMAIL PROTECTED]
_______________________________________________
Kaboodle-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/kaboodle-devel

Reply via email to