BT source code learning experience (14th): client source code analysis (blocking Management in peer-to-peer connection) Author: Wolfenstein from our previous analysis we can see that when a peer-to-peer connection is established, exchange information through the handshake protocol, so that each connection has a connection object, and then there is a singledownload and upload corresponding to it. This time, we will continue to analyze the handshake protocol, and then introduce the working principle of the choker and Blocking Policy controller. Singledownload does not perform any special operations during initialization. It only creates a baddataguard object and corresponds to it. This object is used to collect information about bad data so as to identify bad peer customers. When you create an upload object, if you already have part of the downloaded data, you can send your own block ownership information (send_bitfield ). Now let's look at send_bitfield. We can see that many send_xxx functions are defined in connection to send a message, and before the connection object definition, defines the constant corresponding to those message types. In addition, most of these send_xxx functions call _ send_message. The function is to add its length (4 bytes) before the message to be sent, and then send it out. If necessary, it will be sent later in the queue. In this way, each _ got_message obtains the message content. Now let's look at the _ got_message. It just takes the first byte, which is the type of the message. In the future, we can check other types of messages. Now let's look at the elift = bitfield section and get the status Bit Array of each other's blocks, so that we can record our own download object, that is, singledownload is called. got_have_bitfield (). This function first checks whether the download is complete, and then checks the number of "false" values in the bit array of the other party, if the download is complete and the "false" value in the bit array of the other party is 0, the download is complete, the connection between the two peer customers is meaningless and can be closed. Then, the self. Have = have statement records the block ownership of the other party. As mentioned above, storagewrapper saves its own block ownership status, while the singledownload object corresponding to each connection object retains the block ownership status of the other party. Then let the piecepicker record a piece of others (got_have, the complete record is a piece of its own, which can be seen in the _ singletorrent code ). The endgame below is a policy mode, indicating that it enters the final stage. It checks all its network requests all_requests (which will be analyzed later ), if the other party has a part (note again, here self. have [piece] indicates that the other party has the piece block instead of its own), so send a message, send_interested (). It indicates that I am interested in you (what you have. If it is not in the final stage, check that you have the block but the other side has it. If so, send_interested (). Note that send_interested () is called once, and the other party knows this meaning. Check the connection. _ got_message and how to handle the message. Is self. Upload. got_interested (). In this function, keep your interested variable as the true value, and then notify choker about it. choker. Interested then chooses whether to perform _ rechoke (). Now we should note the two variables choked and interested. The values of these two variables indicate whether they are blocked or interested. They play a direct role in downloading. Each singledownload and upload object has these two variables. During initialization, both choked and interested are false, so that no actual content (that is, shared resources of the seed files) is circulating, for actual content flow, the values of these two variables must be the opposite of their initial values. That is to say, only when one party is interested in the other, when the other party does not reject you (choked = false), the actual download traffic may exist between you in this direction. In addition, these two variables are consistent in every direction of the network connection, that is, the two variables in upload are consistent with those in singledownload that connects to the other end, if a variable changes, send a message to the peer so that the peer can continue to be consistent. Note that the consistency here refers to the two ends of the network connection, instead of the singledownload and upload corresponding to the local connection object, that is, the singledownload of the local connection is consistent with the upload of the peer client, the upload of the local connection is consistent with the singledownload of the peer client. In the same connection, the download and upload directions may be different, that is, one direction is blocked, another direction is still being downloaded. I have noticed that the change of the interested variable is very easy. As long as the other party finds that there is a block that the other party does not have, this message is sent, and the control of the choked variable has a certain policy. The choker controls the blocking of all connections (_ singletorrent level. During initialization, it ensures that _ round_robin is executed every 10 seconds. When a connection enters, it registers with connection_made. the choker maintains the list of all connections, this list is intentionally disordered. In the BT control policy, we can also see the occurrence of random disordered orders multiple times, because sometimes random numbers are the best strategy. In _ round_robin, first check whether _ rechoke_seed () has been completed. If yes, call _ rechoke_seed () to handle the problem as you have already started. By calculating the remainder of Count % 3, we can ensure that the Code of _ round_robin is executed once three times, because count is only added to _ round_robin. This part of the code selects a choked and interested to put the connection at the beginning of the list at the same time (do not let people like you wait too long ). In _ rechoke (), first select some connections that match the choked state (condition: interested and is_snubbed In the download direction, that is, whether the current time is too short from the last download time), and then sort all these connections according to the download speed. Because a negative number is added, therefore, the download speed is at the top. Then, a quota is calculated based on the maximum number of uploads in the configuration item. The quota cannot be equal to the maximum number of uploads. You can only subtract one of these values and retrieve the first few digits from the list, set a mask flag. Calculate the minimum number of uploads, Count. Count must be at least one. If the minimum number of uploads is greater than the previous quota, the Count value increases accordingly. The following describes how to remove the choke state. First, if the mask is 1, it is unconditionally released. If the mask is not 1, but the count is greater than 0, a count is used to remove the choke state, all other connections are rejected by choke. The choke and unchoke of upload start to notify the other party of the message when the status is determined to change. This time, combined with some of the message interaction processes starting from the connection, introduces the working principle of the blocking Policy Manager of choker. Next time, we will begin to discuss the situation when both parties have agreed to exchange data (choked is false and interested is true.
