[bittorrent] Protocol Deviation in Mainline
ehem at m5p.com
Thu Mar 2 04:22:02 EST 2006
>From: Olaf van der Spek <olafvdspek at gmail.com>
> On 3/2/06, Elliott Mitchell <ehem at m5p.com> wrote:
> > I'm guessing the most likely reason is to allow other messages more often
> > and therefore keep a more accurate picture of the swarm. This though is
> > spurious reasoning, you're still likely to continue in progress pieces.
> > Could be the desire is to more precisely tit-for-tat, but this is also
> That's the reason uau mentioned.
> > spurious because on any links you're going to transfer a lot more than
> > 32KB in one choke-period (10 seconds) so the increased precision simply
> > get overwhelmed. Even the old 32KB is small compared to most files being
> > transfered and bandwidth, why cap at 16KB? (I can't see it doing anything
> > but breaking compatibility)
Ouch, bad place to inline that statement. I'm guessing you were refering
to the second?
So, two questions: First, does (if so, how?) this help? Second, is this
worth misbehaving and violating the protocol specification?
For that second issue, 16KB makes that much of a difference on a 30MB
file? No, I must flat out reject that. Sure if you're a bully that might
make a difference to your pride, but realistically that is silly.
At which point I must say "no" to the second. Place me in the camp saying
screw protocol violators, use 32KB and if they choose to disconnect,
they're only harming themselves.
(\___(\___(\______ --=> 8-) EHM <=-- ______/)___/)___/)
\BS ( | EHeM at gremlin.m5p.com PGP 8881EF59 | ) /
\_CS\ | _____ -O #include <stddisclaimer.h> O- _____ | / _/
\___\_|_/82 04 A1 3C C7 B1 37 2A*E3 6E 84 DA 97 4C 40 E6\_|_/___/
More information about the BitTorrent