BT client source code analysis: Summary

BT client source code analysis: Summary
Author: Ma Ge
Date: 2004-6-24

Overview:
Compared with the tracker server, the BT client is much more complicated. Bram Cohen spent a year full time to complete BT, I guess most of the time is spent on the implementation and debugging of the BT client.
Because the BT Client involves a lot of code, I can no longer go into the details just like analyzing the tracker server. In that case, I am confused and everyone seems to be on the cloud. So the first article will talk about the client's functions, related protocols, as well as the overall architecture of the client and the hierarchy of related classes. In this way, you can be confident in your code analysis.

Client functions:

Without looking at the code, the client needs to complete the following functions based on the BT principles:
1. parse the torrent file, obtain the details of the file to be downloaded, and create an empty file on the disk.
2. Establish a connection with the tracker server and exchange messages.
3. Establish a connection with other peers Based on the information obtained from tracker and download the required file fragments.
4. Listen to a port, wait for the connection from other peers, and upload the file fragments.

Related Protocols:
For the client, it needs to process two Protocols:
1. Track HTTP protocol for interaction with the tracker server.
2. The BT peer protocol that interacts with other peers.

Overall architecture:
In general, the BT client is actually running in the form of a server. This seems a bit difficult to understand, but it does.
Why is it a server?
The main function of the client is to download files, but as a P2P software, it must also provide the upload service, that is, it must wait on a port and wait for other peers connection requests. In this regard, it must run in the form of a server. After analyzing the code, we can see that the RawServer class is reused on the client to implement the network server.
The client code starts with download. py. First, function 1 is completed, and then a server loop is entered. During each loop, functions 2, 3, and 4 are completed. The Rerequester class is responsible for function 2. It adds its own task function to RawServer through RawServer: add_task (), which communicates with the tracker server at intervals. Encoder, Connecter, and other classes are combined to complete functions 3 and 4.

Class hierarchy:

The BT Client involves many classes. First, I will roughly describe the functions of these classes and then give them a hierarchy.

1. RawServer: responsible for implementing network servers

2. Rerequester: responsible for communicating with tracker. It calls RawServer: add_task () and adds its own task function Rerequester: c () to RawServer ().

3. Encoder: A Handler class (mentioned when analyzing the tracker server) that processes connections with other peers and analyzes the read data according to the BT protocol.

Encoder class in Encrypter. in py, there is a Connection class in this file, while in Connecter. there is also a Connection class in The py file. The two Connection classes with the same name are a bit odd. to distinguish them, I rename them E-Connection and C-Connection.

3.1. E-Connection: Responsible for TCP-level connections
The two connections are different because the BT peer-to-peer protocol needs to establish a Connection at two levels. The first is the TCP layer Connection, that is, after the TCP three-way handshake, the Connection is established, which is managed by E-Connection. You can see in the Encoder: external_connection_made () function that once an external Connection arrives, an E-Connection class is created.

3.2. C-Connection: manage connections at the Peer protocol level.
The TCP connection is a BT peer-to-peer protocol connection. It needs to go through two "handshakes" of the BT peer-to-peer protocol. The process is as follows:
For ease of description, assume that one BT client is A and the other is X.
If X initiates A connection to A, after the TCP connection is established, A immediately uses this connection to send A "handshake" message of the BT peer protocol to X. Similarly, once the connection is established, X sends A "handshake" message of the BT peer protocol to. Once A receives the "handshake" Message from X, it considers that the "handshake" is successful and establishes A connection at the BT peer protocol level. I call it "peering connection ". A sends A message and receives A message at the same time. Therefore, the handshake process is A two-way handshake ".
Similarly, for X, because the connection is actively initiated, it waits for A "handshake" message after sending the "handshake" message, then it also thinks that the "peering connection" is established.
Once a peering connection is established, both parties can transmit messages through this connection.

In this way, the answer to one of my questions is answered. That is, if X needs to download data from A, it will establish A connection with. If A wants to download data from X again, does it need to initiate another connection to X again? The answer is obviously no. It uses an existing connection.

That is to say, whether X actively initiates A connection to A or A actively initiates A connection to X, they will have the same effect once they are established. This is different from the network development of the C/S structure.

We can see that in the initialization function of E-Connection, the other party that actively connects sends a "handshake" message, in E-Connection: data_came_in, it will first process the "handshake" message of the other party. This is exactly what I described above.
In E-Connection: read_peer_id (), the last peer id of the "handshake" message is processed. Once it is correct, the "peering Connection" is considered complete,

Self. encoder. connecter. connection_made (self)

In the Connecter: connection_made () function, a C-Connectinon class is created to manage "peering connections. Therefore, the "peering Connection" at the higher layer is managed by C-Connection.

3.3. Connecter: Connector for managing download, upload, blocking, fragment selection, and read/write disks.

Download and upload are not isolated, and they affect each other. The fragment selection algorithm is required for downloading. Blocking should be considered during uploading. After the fragment is downloaded, it must be written to the disk. You also need to read data from the disk during upload.
These tasks are centrally scheduled by Connecter.

Class hierarchy. I use indentation to represent an inclusive relationship.

Encoder:
E-Connection
C-Connection
Upload
SingleDownloader
Connecter
Choker: Responsible for blocking Management
Downloader:
SingleDownloader
Picker: Part selection policy
StorageWrapper:

 

Write this first, and I will add something to it.