Università degli Studi di Pisa Dipartimento di Informatica P2P Systems and Blockchains Spring 2021, instructor: Laura Ricci [email protected]
Lesson 6: BITTORRENT PROTOCOL THE MAINLINE DHT
4/3/2021
Dipartimento di Informatica Laura Ricci Università degli Studi di Pisa The Bittorrent Protocol, the Mainline DHT, 1
BITTORRENT: OVERVIEW
key idea: in 2002, Bran Cohen content popularity exhibits temporal locality (Flash Crowds) e.g. CNN on 9/11, new movie/game release,... goal: efficient content distribution system
initially focused on distributing content efficiently, not on searching
distribute the same file to all peers throughput increases with the number of downloaders an efficient use of network bandwidth single publisher, multiple downloaders
later introduce also searching functionality: Kademlia has many “legal” publishers Blizzard Entertainment using it to distribute the beta of their new game
Dipartimento di Informatica Laura Ricci Università degli Studi di Pisa The Bittorrent Protocol, the Mainline DHT, 2
THE CLIENT SERVER MODEL
Dipartimento di Informatica Laura Ricci Università degli Studi di Pisa The Bittorrent Protocol, the Mainline DHT, 3
BITTORRENT IN A NUTSHELL
more nodes can serve the content, not only one server needs a mechanism to detect which node is currently providing the content introducing the tracker taking trace of who is currently providing the content Joe connects to the tracker announcing the content the tracker now knows Joe is providing the file only for a better visualization nodes are arranged in a circle
Dipartimento di Informatica Laura Ricci Università degli Studi di Pisa The Bittorrent Protocol, the Mainline DHT, 4
BITTORRENT IN A NUTSHELL
a) b) c) Bob wants to download the red content a) it first connect to the tracker and learns that Joe is providing the content b) it establishes a direct connection with Joe c) Joe sends the content, from now on the distribution of the file goes on directly between the peers Bob then announces the tracker that it can also provide the red content
Dipartimento di Informatica Laura Ricci Università degli Studi di Pisa The Bittorrent Protocol, the Mainline DHT, 5
A BITTORRENT GLOSSARY
the peer which is going to share a file generates a descriptor of the file, the file .torrent, and publishes it on a server. the descriptor includes a reference to a tracker, an active entity which coordinates the peers sharing the file swarm: set of peers collaborating to the distribution of the same file coordinated by the same tracker
a picture of a swarm
Dipartimento di Informatica Laura Ricci Università degli Studi di Pisa The Bittorrent Protocol, the Mainline DHT, 6
A BITTORRENT GLOSSARY
seeder: peer which owns all the file parts at starting time: a single seeder S exists, the peer publishing the content, creates the file .torrent e publishes it if S leaves the network after having “seeded” a set of peers, in the following, new peers become seeders. these are the peers which have downloaded the whole file and are still in the network
leecher: the peer which has some part or no part of the file and downloads the file from the seeders and/or from other lechers. at the beginning, it looks for the .torrent file to start the download
Dipartimento di Informatica Laura Ricci Università degli Studi di Pisa The Bittorrent Protocol, the Mainline DHT, 7
PROTOCOL OVERVIEW
the peer Seeder (grey) is going to share a file 1. upload the .torrent on a Torrent Server 2. opens a connection to the tracker and informs it of its own existence: for the moment, it is the only peer which owns the file
Dipartimento di Informatica Laura Ricci Università degli Studi di Pisa The Bittorrent Protocol, the Mainline DHT, 8
PROTOCOL OVERVIEW
the peer Peer (grey) is going to download file, 3. downloads the file descriptor (.torrent) and opens it through the BitTorrent client 4. opens a connection to the tracker and informs it of its own existence and receives from the tracker a list of peers of the swarm 5. + 6. opens a set of connections with the peers of the swarm.
Dipartimento di Informatica Laura Ricci Università degli Studi di Pisa The Bittorrent Protocol, the Mainline DHT, 9
PROTOCOL OVERVIEW
the peer Peer (grey) is going to download file, 5. + 6. ask other peer abot the parts they own declares its interest in some part of the file goes on exchaning information with the peers in the swarm
if Peer remains online when it has finished the file download, it goes on distributing the file, becoming a seeder
Dipartimento di Informatica Laura Ricci Università degli Studi di Pisa The Bittorrent Protocol, the Mainline DHT, 10
PROTOCOL OVERVIEW: THE P2P PROTOCOL
Dipartimento di Informatica Laura Ricci Università degli Studi di Pisa The Bittorrent Protocol, the Mainline DHT, 11
A SNAPSHOT OF A SWARM
Dipartimento di Informatica Laura Ricci Università degli Studi di Pisa The Bittorrent Protocol, the Mainline DHT, 12
PIECES AND BLOCKS
content is split into pieces (256KB - 2MB)
typically 256/512/1024/2048 kByte one SHA-1 hash per piece in the .torrent file size adapted to have a reasonably small .torrent file piece is the smaller unit of retransmission: each time a piece is fully downloaded, check it (using the SHA1 algorithm) against what the torrent file tells.
if check fails, piece is retrasmitted pieces are split into blocks (16KB)
Dipartimento di Informatica Laura Ricci Università degli Studi di Pisa The Bittorrent Protocol, the Mainline DHT, 13
THE TORRENT FILE
info contained in the .torrent
length on the content in bytes File Name Pieces length (256kB, 512kB, 1024kB, etc.) Concatenation of all pieces SHA-1 hash Announce URL of the tracker (HTTP)
Possibility of announce list for backup trackers Some optional fields creation date, comment, created by,.... md5 hash of the content (optional) not used by the protocol
pieces SHA-1 hash are enough
Dipartimento di Informatica Laura Ricci Università degli Studi di Pisa The Bittorrent Protocol, the Mainline DHT, 14
THE TORRENT FILE
automatically generated by proper tools (maketorrent) or directly by the Bittorrent client
when the .torrent is generated, the tool requires to the client all the set up information
in particular the address of a tracker. may insert the address of a known tracker, for instance: http://www.smarttorrent.com:2710/a nnounce
Dipartimento di Informatica Laura Ricci Università degli Studi di Pisa The Bittorrent Protocol, the Mainline DHT, 15
PEER BOOTSTRAP a peer downloads the .torrent file of the file it wants to download from the tracker
the peer client retrieves the tracker’s URL and connects to it (HTTP GET)
the peer sends to the tracker the information about its identity (identifier, port, etc,..), the number of the peer of the swarm it needs, and other information
the tracker returns a random list of peers already in the torrent
peer ID, peer IP, peer port
typically 50 peers
Dipartimento di Informatica Laura Ricci Università degli Studi di Pisa The Bittorrent Protocol, the Mainline DHT, 16
PEER BOOTSTRAP
tracker for bootstrap and as certification authority, but not involved in file distribution If a .torrent file is certified by the web server, there is no way to corrupt the torrent
each piece SHA-1 hash is in the .torrent file peers exploit the .torrent received from the tracker to check the integrity of the pieces received from the P2P network a peer connects to the some peers returned by the tracker at most 40 outgoing connections remaining peers kept as a pool of peers to connect if needed trackerless Bittorrent in the last versions, use Kademlia DHT to avoid the centralization point of the tracker
Dipartimento di Informatica Laura Ricci Università degli Studi di Pisa The Bittorrent Protocol, the Mainline DHT, 17
THE PROBLEM OF FREE RIDERS
individuals hiding his/her preference for a common good, so avoiding to pay its price and giving to others the burden to pay the good
if there are other individuals interested in the common good, the free rider is aware that he/she can benefit of the common good without paying for it a group of students have to decide if they can buy an electrical appliance for the common apartment someone may hide his/her will of buying the good to avoiding the payment of the price when the good is acquired, it is not easy to prevent the free rider from utilising the common good the presence of free riders is due to the fact that it is difficult to exclude the he/she from utilising the common good
the name derives from the person that gets into a bus without paying the ticket
Dipartimento di Informatica Laura Ricci Università degli Studi di Pisa The Bittorrent Protocol, the Mainline DHT, 18
FREE RIDERS IN BITTORRENT
free riding in BitTorrent: peers that do not put their bandwidth at disposal of the community a complex resolution of the free riders problem, because: no centralized entity that may control the nodes exists it is not possible to impose a given behaviour to the Bittorrent clients, because it is possible to modify the code of the client by a reverse engineering process
several non official BitTorrent clients enables the user to limit the upload bandwidth as they like
Dipartimento di Informatica Laura Ricci Università degli Studi di Pisa The Bittorrent Protocol, the Mainline DHT, 19
FREE RIDERS IN BITTORRENT
a good behaviour of the whole BitTorrent network depends from the “cooperative behaviour” of the peers with respect to the community
requires to eliminate the free riders
a possible approach to solve this problem is based on reciprocity: a client obtains a good service if and only if it gives a good service to the community
“force” the egoist peers to have a good behaviour...
it cannot be done by simply coding honest strategies in the client
another approach:
a dynamic strategy based on connection monitoring
a strategy based on game theory: the Tit for Tat strategy
based on iterated prisoner dilemma problem
implemented by the choking/unchocking algorithm
Dipartimento di Informatica Laura Ricci Università degli Studi di Pisa The Bittorrent Protocol, the Mainline DHT, 20
CHOKING AT A GLANCE
BitTorrent divides the time in round (generally 10 seconds) for each round, decides to whom it wants to send data (upload)
Each connection with a peer in the neighbour set is controlled by the following variables Interested / uninterested: want/do not want a piece from you? Chocked/unchocked: want/do not want to send data to you?
The connection (TCP) are bidirectional, therefore: the local peer decides if it is interested/wants to send data to the remote peer the remote peer decides if it is interested to the local peer/if it wants to chock the local peer
Dipartimento di Informatica Laura Ricci Università degli Studi di Pisa The Bittorrent Protocol, the Mainline DHT, 21
CHOKING AT A GLANCE
all connections start in the state ‘Not Interested’ and ‘Choked’.
to reach a state where a local peer can receive data: the local peer P must send a message “Interested” to the peer from which it wants to perform the download “I would like to ask you some pieces to download” the local peer P must wait for an “Unchoke” message after having sent a message “Interested”, it waits for an “Unchoke” message before sending any request when P receives the unchoke, it starts to ask for pieces ( “Request” message) generally a piece is too large to be sent in a single message pieces sent in blocks
Dipartimento di Informatica Laura Ricci Università degli Studi di Pisa The Bittorrent Protocol, the Mainline DHT, 22
CONNECTION STATUS Each peer maintains for each remote peer it is connected to the following state am_choking: the local peer is choking the remote peer it does not want to send data to the remote peer because the local peer is not satisfied about how this peer collaborates
am_interested: the local peer is interested in at least one piece on the remote peer
peer_choking: the remote peer is choking the local peer the remote peer does not want to send data to the local peer, because it is not satisfied by the collaboration with the local peer
peer_interested: the remote peer is interested in at least one piece of the local peer
The local peer can receive data from a remote peer if the local peer is interested in the remote peer the remote peer unchoked the local peer
Dipartimento di Informatica Laura Ricci Università degli Studi di Pisa The Bittorrent Protocol, the Mainline DHT, 23
CONNECTION STATUS
Dipartimento di Informatica Laura Ricci Università degli Studi di Pisa The Bittorrent Protocol, the Mainline DHT, 24
THE CHOKING ALGORITHM
different versions of the algorithm in different clients, we describe the most used version. each peer, periodically: evaluates, for each neighbour, the download speed in the previous round and decides which neighbours it is going “to choke” unchock a fixed number of peers, the default number is 3.
the decision on which peers to unchock is taken every 10 seconds by each peer and it is based on the download rate on the last X seconds rate
the interval of 10 seconds is chosen so to avoid wasting resources by rapidly choking and unchoking peers.
Dipartimento di Informatica Laura Ricci Università degli Studi di Pisa The Bittorrent Protocol, the Mainline DHT, 25
OPTIMISTIC UNCHOKING
choking only peers that upload the most to the local peers will lead to ignoring peers that recently join the network lack of discovery if the current unused connections are actually better than the used ones or not.
to overcome this limitation, BitTorrent uses optimistic unchoking one random peer is being unchoked: the current download rate from that peer is completely ignored this will allow the new comers to download resources.
every 3 rounds (30 seconds) an interested and choked peer is selected at random
planned optimistic unchoke (POU) it will be unchoked later when the main algorithm is executed
Dipartimento di Informatica Laura Ricci Università degli Studi di Pisa The Bittorrent Protocol, the Mainline DHT, 26
BITTORRENT: CONNECTION STATUS
Download the Bittorrent client from https://www.bittorrent.com/lang/it/
Dipartimento di Informatica Laura Ricci Università degli Studi di Pisa The Bittorrent Protocol, the Mainline DHT, 27
BITTORRENT: CONNECTION STATUS
Dipartimento di Informatica Laura Ricci Università degli Studi di Pisa The Bittorrent Protocol, the Mainline DHT, 28
BITTORRENT: CONNECTION STATUS
Dipartimento di Informatica Laura Ricci Università degli Studi di Pisa The Bittorrent Protocol, the Mainline DHT, 29
BITTORRENT: CONNECTION STATUS
Dipartimento di Informatica Laura Ricci Università degli Studi di Pisa The Bittorrent Protocol, the Mainline DHT, 30
PEER TO PEER PROTOCOL
Peer wire protocol: the actual peer to peer protocol
to exchange pieces of files
the peer which receives a connection request may refuse the connection if the hash does not correspond to any hash of the files it is participating to download if the ID of the peer does not correspond to those received by the tracker
when the connection is established, each peer communicates to the partner the indexes of the pieces of the file which it owns
each peer of a swarm knows the peers distribution within the swarm
Dipartimento di Informatica Laura Ricci Università degli Studi di Pisa The Bittorrent Protocol, the Mainline DHT, 31
PEER WIRE PROTOCOL
Handshake two way handshake to initiate a connection between two peers once initiated, the connection is symmetric contains (68 bytes) Pstrlen=19 (protocol string identifier length) Pstr=“BitTorrent protocol” Reserved (8 bytes) Info_hash Peer ID
Keep Alive sent each two minutes if no message is received from the connection to check if the client has closed the connection
Dipartimento di Informatica Laura Ricci Università degli Studi di Pisa The Bittorrent Protocol, the Mainline DHT, 32
PEER WIRE PROTOCOL: MESSAGES
Bitfield
Dipartimento di Informatica Laura Ricci Università degli Studi di Pisa The Bittorrent Protocol, the Mainline DHT, 33
PEER WIRE PROTOCOL: MESSAGES
Have a message sent from a peer to all other peers in its swarm, indicates that a new piece is completely downloaded and it is available for sharing sent to all the peers a peer is connected to information is useful for torrent monitoring: exactly knows who has what
when a peer receives a Have message, it updates its swarm, indicating that a new peer became a provider of this piece Mainline 5.0.5 comment in source code # should we send a have message if peer already has the piece? # yes! it is low bandwidth and useful for that peer.
Dipartimento di Informatica Laura Ricci Università degli Studi di Pisa The Bittorrent Protocol, the Mainline DHT, 34
PEER WIRE PROTOCOL: MESSAGES
Interested:
sent from a peer A to another peer B to indicate that it is interested in any of the receiver’s resources (pieces). Contains the piece index. Not Interested a message sent after receiving a HAVE message regarding a specific piece to indicate that the sender is not interested in that piece anymore.
Choke/Unchoke required to implement the unchocking algorithm
choke: sent from A to B when A chokes B no request of download from B is accepted by A from now on.
unchoke: sent from A to B when A unchokes B request of download from B are accepted.
Dipartimento di Informatica Laura Ricci Università degli Studi di Pisa The Bittorrent Protocol, the Mainline DHT, 35
PEER WIRE PROTOCOL: MESSAGES
Messages to exchange blocks: Request
of the piece with index
Dipartimento di Informatica Laura Ricci Università degli Studi di Pisa The Bittorrent Protocol, the Mainline DHT, 36
PEER WIRE PROTOCOL: MESSAGES
Piece
Dipartimento di Informatica Laura Ricci Università degli Studi di Pisa The Bittorrent Protocol, the Mainline DHT, 37
PEER WIRE PROTOCOL: MESSAGES
Cancel a peer sent from a peer to another to indicate that it already got a piece and it is not interested in it anymore. used in end game mode only sent from peer A to peer B to cancel a request already sent to peer B for the block
of the piece with index
Dipartimento di Informatica Laura Ricci Università degli Studi di Pisa The Bittorrent Protocol, the Mainline DHT, 38
PEER WIRE PROTOCOL: MESSAGES
Dipartimento di Informatica Laura Ricci Università degli Studi di Pisa The Bittorrent Protocol, the Mainline DHT, 39
BITTORRENT ALGORITHMS
Algorithms for the selection of peers Chocking/ Unchocking (based on the game theory) rewards the most “collaborative” peers, those which have given a larger number of content in the past Optimistic Unchocking
Algorithms For the selection of the pieces of the files Strict Priority Random First Piece
Rarest First End Game
Dipartimento di Informatica Laura Ricci Università degli Studi di Pisa The Bittorrent Protocol, the Mainline DHT, 40
CHOICE OF THE PIECES: ALGORITHMS
Strict Priority
complete the “assembling” of a piece before asking for another piece
Rarest First
download the rarest pieces first
Random First Piece
choose a random piece in the bootstrap phase
Endgame
broadcast the remaining blocks when the file download is going to terminate
Dipartimento di Informatica Laura Ricci Università degli Studi di Pisa The Bittorrent Protocol, the Mainline DHT, 41
CHOICE OF THE PIECES: STRICT PRIORITY
each piece is decomposed into a set of blocks
if a block of a piece has been required, all the other blocks of the same piece are required before requiring another block of any piece
goal: favour a “fast assemblage” of the pieces only the complete pieces may be exchanged with other peers
the chocking algorithm favour the peers which have entire pieces to exchange with the partners
each peer tries to assemble in the fastest way complete pieces
it can complete pieces that it may exchange with other peers
Dipartimento di Informatica Laura Ricci Università degli Studi di Pisa The Bittorrent Protocol, the Mainline DHT, 42
CHOICE OF PEERS: LOCAL RAREST FIRST
each peer knows the pieces owned by the others have a local view of the availability of each piece Rarest Piece Set: the set of pieces with minimal availability updated when the peer receives an Have or a Bitfield Local Rarest First:
select a peer among the rarest catch a “precious piece” to exchange download unique pieces from the seeder
Dipartimento di Informatica Laura Ricci Università degli Studi di Pisa The Bittorrent Protocol, the Mainline DHT, 43
CHOICE OF PEERS: LOCAL RAREST FIRST Goal
If the seeder of a file disconnects from the swarm it is possible that a rare piece is no more available.
This could make impossible the assembly of the entire file.
if a few seeders exist, with a limited upload capacity
guarantee that new downloaders download part of the file from the seeders
so the entire file is replicated and the download load on the seeder is decreased
a peer acquires rare pieces which are requested from other peers
It is chosen by several peer for the download
it is likely that the peer in inserted in the upload lists of several peers
Dipartimento di Informatica Laura Ricci Università degli Studi di Pisa The Bittorrent Protocol, the Mainline DHT, 44
CHOICES OF PEERS: RANDOM FIRST PIECE
initially, a lecher does not own any piece and cannot offer anything to the other peers of the swarm it is important that a peer acquires a piece as soon as possible, to start the negotiation of the pieces with other peers (unchoking algorithm)
the first 4 pieces are downloaded through the random first piece politics: the piece to download is chosen at random.
goal: “fast starting”, after that, the rarest first politics is exploited
rarest first politics is not initially exploited because: the download of a rare peer may be slow the process, because: less piece availability, larger request larger probability to choose a slow peer sharing of upload bandwidth of the owner of the rare piece
Dipartimento di Informatica Laura Ricci Università degli Studi di Pisa The Bittorrent Protocol, the Mainline DHT, 45
CHOICE OF PIECES: ENDGAME
Observation: most downloads slow down when approaching the end of the download (about 99%) peers characterized by low bandwidth slow down when transfer is going to end, the transfer from these peers cannot be overlapped to the download from other peers
End Game Policy the last pieces of the file to download are required to all the peers that own the file to avoid bandwidth waste, when the piece is received from the peer which has requested it, the download started in parallel are cancelled a little waste of bandwidth, since the end game is executed for a small period of time
Dipartimento di Informatica Laura Ricci Università degli Studi di Pisa The Bittorrent Protocol, the Mainline DHT, 46
DHT APPLICATIONS: THE BITTORRENT MAINLINE DHT
Dipartimento di Informatica Laura Ricci Università degli Studi di Pisa The Bittorrent Protocol, the Mainline DHT, 47
DECENTRALIZING THE TRACKER
still a centralized server performs the tracking, but...
providing tracking services requires very little resources compared to distributing the files
can coordinate a larger number of nodes
however...
the tracker node is still the bottleneck
can become the target of several attacks
Bittorrent Mainline DHT decentralizes the tracker services.
Dipartimento di Informatica Laura Ricci Università degli Studi di Pisa The Bittorrent Protocol, the Mainline DHT, 48
KADEMLIA IN THE BITTORRENT CLIENTS
Kademlia is the protocol used by the largest public DHTs.
Vuze (before known as Azureus), version 2.3.0.0 introduced the DHT for trackerless clients
Bittorrent Inc. introduces its own DHT; incompatible with that of Vuze.
mainline DHT
the largest existing Distributed Hash Table
by 2015 users of Mainline DHT are from 10 million to 26 million, with a daily churn of at least 10 million
mainline DHT is a BEP (BitTorrent Enhancement Proposal) subject to continous revisions
Kademlia improvements
routing table management
look-up
Dipartimento di Informatica Laura Ricci Università degli Studi di Pisa The Bittorrent Protocol, the Mainline DHT, 49
THE MAINLINE DHT
main purpose of the Bittorrent Mainline DHT to provide a “trackerless” peer discovery mechanism to locate peers belonging to a swarm ask to the DHT, instead of the tracker!
each node of the DHT:
stores a part of the tracker information
now each peer implements two different functionalities
a client/server listening on a TCP port that implements the BitTorrent wire protocol. a client/server listening on a UDP port implementing the distributed hash table protocol.
Dipartimento di Informatica Laura Ricci Università degli Studi di Pisa The Bittorrent Protocol, the Mainline DHT, 50
THE MAINLINE DHT PROTOCOL a DHT plays the role of the tracker and stores the content's infohash (key) the list of the peers in the swarm (value)
protocol messages: PING: probe a node’s availability or announce one's existence if the node fails to respond for some period of time, it will be purged out of the routing table.
GET_PEERS (H): look for peers belonging to the swarm for the content with InfoHash H. The contacted node may
store peers for H, replies with a PEER message containing them OR have no info for H: replies with the identifiers of the 8 peers closest to H.
Dipartimento di Informatica Laura Ricci Università degli Studi di Pisa The Bittorrent Protocol, the Mainline DHT, 51
THE MAINLINE DHT PROTOCOL
a DHT plays the role of the tracker and stores the content's infohash (key) the list of the peers in the swarm (value)
protocol messages:
ANNOUNCE_PEER : a peer announces it belongs to a swarm.
FIND_PEER (target_id) : request for nodes which are close to the node with node ID target_id.
the next slides show an example of announcing infohash and finding a swarm through the Mainline Distributed Hash Table.
Dipartimento di Informatica Laura Ricci Università degli Studi di Pisa The Bittorrent Protocol, the Mainline DHT, 52
THE MAINLINE DHT: AN EXAMPLE
● first step: assign an identifier
● to the pink content
● to each Bittorrent node
Dipartimento di Informatica Laura Ricci Università degli Studi di Pisa The Bittorrent Protocol, the Mainline DHT, 53
THE MAINLINE DHT: AN EXAMPLE
● second step: ● Joe generates the tracking info, containing the ID of the node and the Info to connect to the node (IP Address, Port) ● store the info on the node that is closest to the content key (and replicate it in the closest nodes, not shown)
Dipartimento di Informatica Laura Ricci Università degli Studi di Pisa The Bittorrent Protocol, the Mainline DHT, 54
THE MAINLINE DHT: AN EXAMPLE
● Alice wants to download the pink content (identifier 14) ● she already knows some peers in the DHT (dotted lines)
Dipartimento di Informatica Laura Ricci Università degli Studi di Pisa The Bittorrent Protocol, the Mainline DHT, 55
THE MAINLINE DHT: AN EXAMPLE
● Alice sends the message getPeers(14) to the node (13) with the identifier closest to 14, in terms of XOR distance
Dipartimento di Informatica Laura Ricci Università degli Studi di Pisa The Bittorrent Protocol, the Mainline DHT, 56
THE MAINLINE DHT: AN EXAMPLE
● node 13 does not have any tracking information for node 14 ● ...but it returns the closest nodes to 14 it knows, suppose it is 15
Dipartimento di Informatica Laura Ricci Università degli Studi di Pisa The Bittorrent Protocol, the Mainline DHT, 57
THE MAINLINE DHT: AN EXAMPLE
● Alice has not yet obtained the tracking information ● she requests the tracking information from 15
Dipartimento di Informatica Laura Ricci Università degli Studi di Pisa The Bittorrent Protocol, the Mainline DHT, 58
THE MAINLINE DHT: AN EXAMPLE
● 15 has tracking information for the pink content
● it returns information about all the peers providing the file ● Joe, with ID=4, together with information to connect to Joe
Dipartimento di Informatica Laura Ricci Università degli Studi di Pisa The Bittorrent Protocol, the Mainline DHT, 59
THE MAINLINE DHT: AN EXAMPLE
● Alice can connect to Joe and receive a copy of the content
Dipartimento di Informatica Laura Ricci Università degli Studi di Pisa The Bittorrent Protocol, the Mainline DHT, 60
THE MAINLINE DHT: AN EXAMPLE
● after having received the file, Alice announces to the network she is also providing a copy of the file ● announce message
Dipartimento di Informatica Laura Ricci Università degli Studi di Pisa The Bittorrent Protocol, the Mainline DHT, 61
THE MAINLINE DHT: AN EXAMPLE
● Announce message from Alice is received from Node 15
Dipartimento di Informatica Laura Ricci Università degli Studi di Pisa The Bittorrent Protocol, the Mainline DHT, 62
THE MAINLINE DHT: AN EXAMPLE
● node 15 adds Alice to the tracker information ● from now on, other nodes can connect to Alice or to Joe to download the content
Dipartimento di Informatica Laura Ricci Università degli Studi di Pisa The Bittorrent Protocol, the Mainline DHT, 63
OTHER APPLICATIONS OF KADEMLIA Kad Network: developed originally by the eMule community to replace the server-based architecture of the eDonkey2000 network Ethereum: The node discovery protocol in Ethereum's blockchain network stack is based a slightly modified implementation of Kademlia. Overnet network: With KadC a C library for handling its Kademlia is available. (development of Overnet is discontinued)
Osiris: used to manage distributed and anonymous web portal. Retroshare: F2F decentralised communication platform with secure VOIP, instant messaging, file transfer etc. Tox: A fully distributed messaging, VoIP and video chat platform IPFS: A peer-to-peer distributed filesystem. TeleHash: a mesh networking protocol that uses Kademlia to resolve direct connections between parties.
OpenDHT
Dipartimento di Informatica Laura Ricci Università degli Studi di Pisa The Bittorrent Protocol, the Mainline DHT, 64