PDA

View Full Version : Firewall's sum bandwidth does not match Kazaa's


kcin
July 6th, 2003, 01:52 PM
When connected to the Net I sometimes check my firewall (Kerio) to see who's knocking on the door. Kerio also shows the current total receive and transfer speeds of my network connection.

When downloading with Kazaa I often see that the sum receive bandwidth indicated by the firewall is much higher than the one indicated by Kazaa Lite.

For example, I dload 2-3 files at once with Kazaa and I see that the total speed is, say, 30KB/sec (the sum of all downloads, the total download speed). When I check the value in Kerio, it shows that total receive speed is 40-50KB/sec, sometimes 60 KB/sec. Of course, there is no other bandwidth eating app running (beside Kazaa) when I check this.

What's the reason of this difference? Does the Kazaa protocol have such an overhead? Or is it something else?

kcin
July 6th, 2003, 01:57 PM
I forgot to mention that the more files I download simultaneously the greater the difference is between the total speed indicated by KLite and the firewall.

cpugeniusmv
July 6th, 2003, 02:05 PM
that's pretty commonplace, your firewall and kazaa don't show the usage in realtime, they show it like once every second...and the two programs may not be in sync with one another.

their timers start at different times, and they calculate how many KB's were downloaded in each second on their timers.

DainBramaged
July 6th, 2003, 02:07 PM
It shouldn't match. Kazaa reports bandwidth that only it uses. On any connection, there is much traffic that happens more or less behind the scenes that firewalls or other D/U meters will catch. Kazaa will not.

cpugeniusmv
July 6th, 2003, 02:12 PM
Originally posted by DainBramaged
It shouldn't match. Kazaa reports bandwidth that only it uses. On any connection, there is much traffic that happens more or less behind the scenes that firewalls or other D/U meters will catch. Kazaa will not.

that too lol.

kcin
July 6th, 2003, 02:16 PM
Ok, but the firewall shows all the active connections and there is no other application with network activity when I compare the values, so they should match.

I can see the speed of all the individual Kazaa connections (to different sources) in the firewall's window, not just the sum and their speed are really higher than the values Kazaa indicates.

That's why I think it might be protocol overhead, since Kazaa shows only the effective bandwidth, but the firewall measures all Kazaa traffic. On the other hand, I don't think Kazaa's protocol is that bad (50-100% overhead), but if it's not protocol overhead, then what?

cpugeniusmv
July 6th, 2003, 02:34 PM
Originally posted by kcin
Ok, but the firewall shows all the active connections and there is no other application with network activity when I compare the values, so they should match.

I can see the speed of all the individual Kazaa connections (to different sources) in the firewall's window, not just the sum and their speed are really higher than the values Kazaa indicates.

That's why I think it might be protocol overhead, since Kazaa shows only the effective bandwidth, but the firewall measures all Kazaa traffic. On the other hand, I don't think Kazaa's protocol is that bad (50-100% overhead), but if it's not protocol overhead, then what?

read my first post.

kcin
July 6th, 2003, 02:36 PM
cpugeniusmv,

I haven't seen your reply before. Yes, I know that the measurements of Kazaa and the firewall are not simultaneous, but in the long run they should match.

E.g. Kazaa shows 30 KB/sec in total, the firewall 50KB/sec. When I check the values repeatedly for 5 minutes, kazaa shows around 30 KB/sec, and the firewall 50KB/sec the whole time. So it cannot be explained with different timers, since the difference should diminsh in this case over time.

BTW, has anyone else experienced this difference? Or no one bothered to check?

cpugeniusmv
July 6th, 2003, 02:39 PM
i think everyone experiences that same thing, but if my previous post isn't the explanation...i don't know what is.

.::BeatFactory::.
July 6th, 2003, 03:13 PM
could it be because of the TCP/IP stack sending back confirmation packets that it actually received data? or maybe packets that had errors and were not accepted?

.::BeatFactory::. could be wrong ...