Archived from groups: microsoft.public.windowsxp.general (
More info?)
On Tue, 21 Jun 2005 05:25:04 +1000, "David Candy" <.> wrote:
>That's because you are thieving other's connections. That means you are a thief.
>You are preventing others from using the internet and making web sites pay larger
>licensing fees.
Oh, please.
Chances are that bandwidth sensitivities will be protected from the
server side, where these exist.
For example, many sites use a "read these squiggly random characters
and type them in" UI to block automated bots. When it comes to
hammering resources, even the piggiest human is hard-pressed to
compete with a bot; it's like trying to out-fart a factory, in the
context of air pollution. You can't swallow that many beans.
For example, if your ISP's conduits are the limiting factor, the ISP
may impose any or all of the following:
- Terms and Conditions; get kicked off if you break 'em
- monthly capacity cap, e.g. 2G per month
- limit on number of simultaneous recipients when sending mail
- have to be dialed in via ISP to send mail through ISP
- some sort of "simultaneous download limit"
- minimum permitted modem speed
- extra cost for higher bandwidth e.g. ADSL vs. modem
- limit to number of PCs logged in a at a time (NAT?)
It's interesting that out of all of the above, I haven't heard
anything from ISPs about how many downloads, web browser windows,
streaming media sessions etc. you may have at a time, so that doesn't
seem to be an issue for them. P2P sharing, shared resource projects a
la SETI, listening to streaming media such as Internet radio etc. may
impact more than downloading anyway.
For example, a site may limit the number of simultaneous connects you
may have, and either enqueue you or kick you off if you exceed these.
They can track this by IP address (number of simultaneous downloads)
or requests to download from arbitrary points in the file (multipoint
multi-track downloads as per download accelerators).
The site may have different issues.
If it's bandwidth as such, they will hate download accelerators and
high visitor connect speeds (e.g. they'd prefer doling out data at 2ks
a la DUN than 50ks a la ADSL).
But if it's number of connections, they may welcoms fast visitors who
spit and get off the pot quickly, rather than some 14400bps dozeball
who pulls 2 bytes a minute and ties up a connection for 10 hours to
download a 20k patch. Then it's a question of whether multipoint
multi-track acceleration counts as one connection per track.
In practice, I often find that busy servers tend to timeout and kick
off slow (DUN) connects while working fine on ADSL. For example, if a
new malware requires an av vendor to ship a new engine, so the usual
daily 500k update is now a 5M monster, that has to be served to the
same number of visitors wanting updates, it gets ouchy for DUN, even
though the DUN connect is surely not "flooding" the bandwidth.
I looked at (rather than through) that RFC, and MEGO - so I can't say
if MS's assertion is correct or not. Nice to see them on the pious
side of the standards fence for once, if it is so.
>-- Risk Management is the clue that asks:
"Why do I keep open buckets of petrol next to all the
ashtrays in the lounge, when I don't even have a car?"
>----------------------- ------ ---- --- -- - - - -
Facebook
Twitter
Instagram