[BitTorrent] Plans for Multicast?
bill at viasic.com
Mon Jan 17 16:49:40 EST 2005
On Mon, 2005-01-17 at 16:45 +0000, Justin Cormack wrote:
> > Hi,
> > I've looked at how BitTorrent work. It is a very good protocol design.
> > But if I look at my Upload/Download-ratio from Bittorrent and from my
> > last-mile-ADSL I'm missing support for an parallel-existing and
> > cross-excanging multicast deployment tree where possible.
> > In fact I think on an hybrid protocol between (Fat)Nemo and
> > BitTorrent.
> > As an given Example see . Distribute torrents over the Internet per
> > Unicast and within the (NAT-less) LAN over Multicast. For End-Users
> > it is currently not really possible to distribute files in these
> > manner because of the lack of Applications doing so.
> > Are there any plans to implement such a feature?
> BT works best if peers have different blocks, and as peers that are on
> networks that support multicast are normally on local lans where traffic is
> cheap compared to offsite traffic, multicast does not offer much benefit.
> If long haul routed multicast existed things might be different.
I took a quick tour of the multi-cast tutorial at:
>From my point of view, it would be ideal if multicast simply allowed me
to specify multiple addresses for a message to be sent to. AFAIK, it
doesn't. Instead it is a very complex mechanism designed for
distributing real time video signals, rather than BitTorrent packets.
Also, since much of the core of the internet has multicast disabled, it
probably wouldn't help much in the near-term, except possibly on local
nets where it's value is less. The situation for multicast seems to me
to be the same for IPv4 and IPv6.
But what the heck, it's still fun to talk about how we might use it if
it were widely available... I'm not recommending we take action on any
of these ideas. There just ideas:
Trackers could define groups of peers that belong to a multicast group.
Let's call this a peer group. The tracker could mass broadcast peer
ids, rather that doing it one at a time. Also, HAVE messages could be
multi-cast to the peer group. This would eliminate a lot of
BitTorrent's overhead, although it's not very high now. The reduced
load on the trackers might interest the big torrent sites.
For distributing data, each peer might define his own multicast group.
They could announce to the peer group an order for broadcasting pieces,
and announce progress as pieces are sent. That way, peers could join in
just before a piece of interest was broadcast, and leave the group just
There are lots of issues with this, other than the poor availablity of
multicast. For example, how do you reward peers for uploading to a
multicast group? Right now, if you don't upload, you don't get to
download very fast. AFAIK, you can't keep someone out of your multicast
One way might be to accept piece requests from peers who've helped you
with their broadcasts, and try to optimize the download speed for those
who's broadcasts you've benefited from.
Another problem is bandwidth mismatch. What happens to a multicast
packet that is sent too fast for a client to download over his modem?
I'd guess the packets are simply lost. Perhaps the broadcast speed
could be selected by the requester of the piece, further providing
incentive to upload.
I keep trying to think of why multicast can't be used for the piece
transfer, but there seem to be ways... just not trivial ways.
Yahoo! Groups Links
<*> To visit your group on the web, go to:
<*> To unsubscribe from this group, send an email to:
BitTorrent-unsubscribe at yahoogroups.com
<*> Your use of Yahoo! Groups is subject to:
More information about the BitTorrent