[bittorrent] BT protocol Q

Olaf van der Spek olafvdspek at gmail.com
Fri Apr 29 13:49:56 EDT 2005

On 4/29/05, Simon Spero <ses at unc.edu> wrote:
> On Apr 29, 2005, at 12:30 PM, Justin Cormack wrote:
> > Does it really happen other than when the peer has actually gone down
> > but tcp hasnt timed out yet? There is very little overhead in having
> > quite large numbers of requests outstanding at a time.
> It happens quite a bit;  I haven't quantified it over  a large
> population yet.   I expect that the primary culprit are highly
> asymmetric links, a la DSL.
>  If a DSL peer begins a transfer, it must have queued up requests
> for data in proportion to the ratios of expected throughput in each
> direction.   Since bittorrent clients only have weak ability to
> predict this  throughput,  this is a hard measure to calculate, and
> can waste bandwidth if cancel requests need to be sent but can't.
>  Since transfer block sizes really need to be exactly the  same size
> as the entire piece, this problem can be significant.

A request is for a chunk (16/32 kb), not a piece.
And instead of two TCP connections, it'd IMO be better to change the
protocol to allow better interleaving of data and other stuff.

More information about the BitTorrent mailing list