The Bittorrent Overlay SwarmPeers in BitTorrent normally only communicate with each other when they are downloading the same file. To facilitate communication outside the context of a particular swarm, we introduce a special overlay swarm of which all Tribler clients are part by default. By designing this communication channel as a BitTorrent swarm, it can be easily build into existing clients and does not require extra TCP listen ports. The latter implies that no extra configuration of firewalls or Network Address Translators (NATs) is required by the user. The recommendation and cooperative download extensions both require new BitTorrent-protocol messages. We implemented a clean method for extending the protocol because our aim is to include more features in the future. Another requirement is being the least invasive in existing implementations. Furthermore, the current BitTorrent protocol does not allow communication outside the context of a swarm, that is, clients can only communicate with clients that are downloading the same file. For our extensions, we must be able to communicate outside the context of a single file swarm. We therefore created a new virtual swarm that encompasses all peers that are using the system, called the overlay swarm for high-level communication between peers. The swarm to which a peer connection belongs is defined by the infohash field during the initial BitTorrent handshake. This infohash normally contains the SHA1 hash of the contents of the torrent file. In case of the overlay swarm, the infohash must contain a value of all zeros. The overlay swarm has no central BitTorrent tracker. A peer that wants, for example, to exchange preference lists with another peer must use the overlay swarm. The peer connects to the other peer's listen socket and uses the zero infohash value in the handshake. If the handshake is successful both parties know that new extension messages can be exchanged. After connecting to a peer on the overlay swarm the peers must run the challenge/response protocol to exchange and validate their PermIDs before any other communication. By using this non-valid infohash value we remain fully backwards compatible and also are minimally invasive to the BitTorrent protocol. This overlay can be extended in the future with new messages for secure gossip, sharing ratio enforcement, social networking, voting/moderation, reputation management, etc. |