One end of the source code analysis BT customers: Overview Author: Ma Ying-jeou Date: 2004-6-24
Overview: Compared to the Tracker server, the BT client has more complicated, BRAM Cohen spent a year of Full Time time to complete BT, I estimate that most of the time is used in the implementation and debugging of the BT client. Since the code involved in the BT client is more like analyzing the Tracker server, go to the details, then, if I wrote, I don't know what it is. So the first article first talks about the client's function, related protocol, and the hierarchy of the client's overall architecture and related classes. In this way, after the overall grasp, everyone can make the chest with Chengzhu in the process of analyzing the code itself.
The functionality of the client:
Do not look at the code, only according to the relevant principles of BT, can be roughly speculated that the client needs to complete the following features: 1. Pay the Torrent file to get the details of the file you want to download, and create an empty file on the disk. 2, establish a connection with the Tracker server and interactive message. 3, according to the information obtained from Tracker, establish a connection with other Peers, and download the required file clips 4, listen to the port, wait for other PEERS connections, and provide upload of the file snap.
Related Agreements: For the client, it needs to handle two protocols: 1. Track HTTP protocol interact with the Tracker server. 2, BT peers interact with other PEERS.
Overall Architecture: From a general point, the BT client is actually run in the form of a server. This seems to be a bit difficult to understand, but it is true. Why is a server? The main function of the client is to download files, but as a P2P software, it must provide upload services, that is, it must wait on a port, waiting for other Peers's connection requests. From this point of view, it must be run in the form of a server. When we actually analyze the code, we can see that the client is used to use the RawServer class to implement the web server. The client's code starts from Download.py, first complete the function 1, then enter the server cycle, and during each cycle process, the functions 2, 3, 4 are completed. Among them, the Rerequester class is responsible for completing the function 2, which adds its own task function to RawServer :: add_task (), to RawServer, and communicate with the Tracker server every other time. ENCIDER, Connecter and other classes are combined, complete features 3 and 4.
Class hierarchy:
There are many classes involved in the BT client, and I first describe these functions, then give them a hierarchy.
1, Rawserver: Responsible for the implementation of web server
2, Rerequester: Responsible and tracker communication. It calls RawServer :: add_task (), adds its own task function back to RawServer Relenter :: C ().
3, ENCIDER: A Handler class (mentioned in the analysis of the Tracker server), responsible for processing the connection with other Peers to analyze and analyze the read data according to the BT peer protocol.
Encoder class in encrypter.py, in this file, there is a CONNECTION class, and there is a CONNECTER.PY file, there is a CONNECTION class, which is some embezzle, in order to distinguish it, I rename them to E-Connection and C-Connection. 3.1, E-Connection: The two connection works in the TCP hierarchy is different because the BT peer protocol needs to establish a connection at two levels. The first is the connection at the TCP hierarchy, that is, after the TCP's three handshakes, establish a connection, which is managed by E-Connection. As you can see in the Encoder :: External_Connection_made () function, once an external connection is connected, create an E-Connection class.
3.2, C-Connection: Manage the connection at the peer protocol level. On the TCP connection, it is the connection of the BT peer protocol. It needs to see two "handshake" by BT peer agreement, and the details of the handshake are to see the BT peer agreement. The process is this: For convenience, we assume that a BT client is A, and the other client is X. If the X active is initiated to the A, then after the TCP connection is established, the A immediately uses this connection to the "handshake" message of the BT peer protocol. Similarly, X When the connection is established, send a "handshake" message of the BT peer protocol to a. A Once the "handshake" message is received, then it thinks "handshake" successfully established a connection at the BT peer protocol level. I called it "peerless connection." A sent a message while receiving a message, so this handshake process is two "handshake". Similarly, for X, because the connection is initiative, it will wait for a "handshake" message after sending "Handshake", if it is received, then it also believes that "peer connection" is established. . Once "Peer connection" is established, the two sides can pass the message through this connection.
In this way, there is a question that I have doubtful. Yes: If x needs to download data from A, then it will establish a connection with A. If a also wants to download data from x, it needs to be re-initiated to initiate another connection? The answer is obviously not, it will use an existing connection.
That is, regardless of the connection initiated to the A, it is the same as the connection to the X, and once it is established, their effect is the same. This is different from network development of our C / S structure.
We can see that in the E-Connection initialization function, the other party that actively connects to the "handshake" message, in E-Connection :: DATA_CAME_IN (), will first process the other party's "handshake" message. This is exactly what I described above. In e-connection :: read_peer_id (), it is handled for the last Peer ID of the "Handshake" message. Once it is correct, then "peer connection" is complete,
Self.Encoder.connecter.Connection_made (Self)
In the Connecter :: Connection_Made () function, a C-Connectinon class for administering "peer-to-peer connections" is created. Therefore, a higher level of "peer-to-peer connection" is managed by C-Connection.
3.3, Connecter: Connector, Manage Download, Upload, Block, Pieces, Select, Read and write Disks, etc. Download and upload is not isolated, they affect each other. Downloading requires a fragment selection algorithm. When uploading, consider blocking, after the segment download, you want to write it on the disk. When uploaded, you also need to read from disk. These tasks are constructed by Connecter to unify.
The class hierarchy, I use it to indicate a relationship.
ENCODER: E-Connection C-Connection Upload SingleDownloader Connecter Choker: Responsible to block the management Downloader: SingleDownloadloader Picker: Piece Select Policy StorageWrapper:
Write these first, there is anything I added again.
