[bittorrent] super-seeding and HAVE messages

Elliott Mitchell ehem at m5p.com
Sun May 7 16:06:24 EDT 2006

>From: Petter Nilsen <pettern at opera.com>
> Consider http://wiki.theory.org/BitTorrentSpecification:
> On the HAVE message, it states the following:
> "Implementer's Note: That is the strict definition, in reality some games  
> may be played. In particular because peers are extremely unlikely to  
> download pieces that they already have, a peer may choose not to advertise  
> having a piece to a peer that already has that piece. At a minimum "HAVE  
> supression" will result in a 50% reduction in the number of HAVE messages,  
> this translates to around a 25-35% reduction in protocol overhead."
> However, it seems to contradict what is written under super-seeding:
> "When the client has finished downloading the piece, the seed will not  
> inform it of any other pieces until it has seen the piece it had sent  
> previously present on at least one other client. Until then, the client  
> will not have access to any of the other pieces of the seed, and therefore  
> will not waste the seed's bandwidth."

Yes, where is the contradiction you speak of? The super-seed isn't
waiting for a HAVE message from the peer it sent the piece to, it is
looking for a HAVE message from another peer that it didn't send the
piece to (evidence that the target has passed the piece along). The peer
that first received the piece might not send back a HAVE message, since
it knows the super-seed has the piece; but other peers don't know the
super-seed has a the piece and therefore would send HAVE messages to the

> Now, this is a problem with eg. Azureus which will not send another HAVE  
> message to the peer it just sent a complete piece to, if the peer  
> implements the HAVE message protocol optimization and does not send a HAVE  
> message to the super-seeder (as it knows the super-seeder already has the  
> piece).

You're surprised that Azureus is broken? I'm finding myself a bit of a
curmudgeon here. There are zillions of extensions proposed that attempt
to produce somewhat better results by increasing knowledge of the swarm.
Problem is 99.9% of these result in massive increases of both protocol
and client complexity. At the same time those performance improvements
tend to be unimpressive.

Please notice, most often those pieces of software and protocols that
survive the test of time are *simple*. Compare TCP/IP and SMTP to all the
other protocols out there. Basic implementations of either are pretty
simple, they won't produce great performance, but they'll be quite
effective. There are a zillion things that could of been done to TCP/IP
to produce better performance, but those fell by the wayside because they
were too complex and didn't produce sufficient performance improvement.

Message to everyone here, KISS. BT is at the core pretty simple and
pretty effective. There are lots of things needed to produce good
performance, but good results are easy to produce without too much
complexity. Nearly every proposed addition produces massive increases in
complexity, for trivial gains under rare circumstances. Though they don't
give you the warm fuzzy feeling, stochastic algorithms are quite


> Any recommendation on what can be done here?   Keeping the optimization of  
> HAVE messages is tempting, but not if it causes problems in super-seeder  
> mode.

Those two don't conflict. Optimizing the HAVE messages is based on a
simple observation, peers will never download pieces they already have
(at least no sane ones will). Notice though that this behavior is
perfectly protocol compliant, nothing forces you to send HAVEs.

What may cause a problem is peers that attempt to model network behavior
based on receiving those HAVEs. By not sending these unnecessary HAVEs
you'll mess up their model of the swarm. As you're operating perfectly
within the bounds of the protocol, I blame these peers because they're
attempting to use huge amounts of code complexity to produce trivial gain
and depending on a behavior that isn't required by the protocol

(\___(\___(\______          --=> 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 mailing list