Re: BT repeater?

Any caching system like this does need to modify the protocol (well there
are ways of getting round it). The basic problem is if you drop a piece
as you are out of disk space you need to send donthave messages so no one
asks you for it.

The alternative is to write a cache that just exits when it needs to make
more space, deletes some stuff, and then starts up again - this will slow
downloads in progress.

In order to not change the wire protocol, it would be possible to simply send a
new bitmap that overrides the old one at any time, but clients would have to
be modified to accept this.

> 
> 
> 
> Hi.
> 
> BT suffers from a basic problem: down-loaders of big files typically
> leave the torrent after downloading.  This leads to an average
> upload/download ratio of at around 1/1.  Since most of us upload much
> slower than we download, this is bad.
> 
> I think more of us would be willing to leave our BT clients running
> with lots of torrents open, except that:
> 
> - It uses too much disk space to remain in lots of torrents
> - It is difficult joining and managing lots of torrents
> 
> For example, I just upgraded to Linux FC3, and downloaded 2.3G of
> data.  I burned the DVD, and had to remove the data to save disk
> space.  I might be willing to donate upload time to another torrent
> with smaller files, but which one?  I cannot simply look at a list of
> web links and predict the torrent that would benifit the most.
> 
> I think both of these problems can be solved.  In particular, I think
> that a modified client could do the job without modifying the BT protocol.
> 
> In effect, I'm suggesting writing a BT repeater in a multi-cast
> system.  Of course, IPv6 already does this, but that might not become
> real for many years.
> 
> Here's how I imagine the modified client working:
> 
> - The client would automatically download all .torrent files from a
> list of user-supplied .torrent file servers.
> - The client would examine the various torrents to find ones that
> needed additional bandwidth.
> - The client would enter the torrent(s) that need it's bandwidth the most.
> - To limit space on the hard-drive, only a user-specified sized cache
> would be used for writing pieces of files.  A typical cache might be
> from a few MB to a few hundred MB.
> - The client requests a set of least-available file pieces from it's
> torrents, but only enough to fill up the cache.
> - The client downloads these pieces, and then servers them up to its
> torrents.
> - When a file piece is no longer in demand, the client deletes it, and
> downloads a new piece that is in demand.
> - When a torrent no longer needs the repeater function, the client
> leaves it, and joins the torrent that needs it the most.
> - When the user of the client requests a file download, the repeater
> function gets suspended until the requested file is fully downloaded.
> 
> What do you think?
> 
> Bill Cox
> 
> 
> 
> 
> 
> 
> 
>  
> Yahoo! Groups Links
> 
> 
> 
>  
> 
> 
> 



------------------------ Yahoo! Groups Sponsor --------------------~--> 
$4.98 domain names from Yahoo!. Register anything.
http://us.click.yahoo.com/Q7_YsB/neXJAA/yQLSAA/dkFolB/TM
--------------------------------------------------------------------~-> 

 
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:
    [email protected]

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