forked from quentin/quentin.dufour.io
61 lines
1.7 KiB
Markdown
61 lines
1.7 KiB
Markdown
---
|
|
layout: post
|
|
slug: understanding-bittorrent
|
|
status: draft
|
|
sitemap: false
|
|
title: Understanding BitTorrent
|
|
description: From the network perspective
|
|
categories:
|
|
tags:
|
|
- p2p
|
|
- distributed system
|
|
---
|
|
|
|
In this blog post, we will only review the core of BitTorrent.
|
|
We are not interested in its extensions, its optimizations, how it manages spam, etc.
|
|
|
|
Compared to the specifications, we will focus our analysis on the importance of parameters and the emerging behaviours that arise when many BitTorrent clients communicate together.
|
|
Moreover, as this (hopefully series of) article will be written in a goal to evaluate Peertube planned implementation of "webstream" (live-streaming over webtorrent), we will use the webtorrent implementation as reference for everything outside specifications.
|
|
|
|
We will also try to connect BitTorrent design to some academic papers to put things in perspective.
|
|
|
|
## A problem well stated is a problem half solved
|
|
|
|
**Discover content**
|
|
|
|
**Discover peers**
|
|
|
|
**Discover peers' content**
|
|
|
|
**Induce a desirable emerging behavior**
|
|
|
|
## The .torrent file
|
|
|
|
Describes the content of the file to download.
|
|
Multiplexing.
|
|
|
|
## The role of the tracker
|
|
|
|
Discovering peers.
|
|
What property it must enforce.
|
|
Random sample of the network
|
|
You will have some neighbors.
|
|
|
|
## Discovering the chunks known by your neighbors
|
|
|
|
introduce some Xerox Taxonomy {% cite DBLP:journals/sigops/DemersGHILSSST88 %}.
|
|
"bitfield" puis "have" -> le push sur l'anti entropy
|
|
If it's done symmetrically, we are in a push+pull model.
|
|
|
|
## Downloading the data
|
|
|
|
The importance of Local Rarest First {% cite DBLP:conf/infocom/BharambeHP06 %}
|
|
|
|
## Conclusion
|
|
|
|
BitTorrent is efficient as it multiplexes chunks.
|
|
|
|
## References
|
|
|
|
{% bibliography --cited %}
|
|
|