Have compression (was Re: Standards (was [BitTorrent] Back to

Justin Cormack justin at street-vision.com
Wed Feb 9 06:00:32 EST 2005


> 
> 
> Justin Cormack wrote:
> > Olavs protcol lets you request in 32k chunks (and verify) but you can only
> > send have messages in this predetermined size set by whover made the
> > torrent. Lets junk the fixed piece size, and see what the options are.
> 
> How often do I have to point out the chunk_have mssage?

You dont give any strategy for when to use it, and you suggested that 
basically clients were expected to use the piece have message, so I ignored it.
 
> > Here is one suggestion
> > 
> > Lets change the have (and request etc) messages to look like
> > uint32_t clen
> > uint8_t message_type
> > uint8_t log
> > uint32_t piece
> 
> Should response messages still match request messages or are you allowed 
> to send only part of the requested range?

Thats an inetresting one. I was assuming they matched (hence my suggestion
to modify the unchoke to say how much you would be allowed). You could
also allow them to differ and use this to measure how much you are being
choked. I think either way giving clients this information about choking
is a good thing.

> > Now this doesnt buy us anything if we send a have message after each chunk,
> > but we now have the ability to dynamically vary piece size. First thing we
> > think about is how large a piece can we request in one go. Clearly if we
> > request really big pieces (the whole file!) we send fewer have messages but
> > increase the latency of them.
> 
> What's the definition of latency here?

Latency is the time between when you download something (the minimum
downloadable unit) and when you announce a have so another client can get it
from you. It clearly has a major effect on throughput. Note the BT1 way of
having a minimum downloadable unit (chunk) smaller than the verifiable unit
unavoidably increases latency, probably by too much or the endgame stuff
wouldnt be needed.

> > First thing we notice is that we dont have to send messages at the same rate
> > to all peers. If we are choking them, we dont need to send any messages
> > until the point we unchoke, so we can batch them. Another strategy is to send
> > have messages for rare pieces immediately to the peers that dont have them,
> 
> What's rare for you doesn't have to be rare for somebody else.

Within the set of peers you can see. It should be a random sample so you
should be able to make judgeements that are probably correct.

> > while you coalesce common ones.
> > 
> 
> 
>  
> Yahoo! Groups Links
> 
> 
> 
>  
> 
> 
> 



 
Yahoo! Groups Links

<*> To visit your group on the web, go to:
    http://groups.yahoo.com/group/BitTorrent/

<*> To unsubscribe from this group, send an email to:
    BitTorrent-unsubscribe at yahoogroups.com

<*> Your use of Yahoo! Groups is subject to:
    http://docs.yahoo.com/info/terms/
 





More information about the BitTorrent mailing list