BT source code learning experience (15th): client source code analysis (block selection policy during download) Author: Wolfenstein last introduced some actions of peer-to-peer customers after the connection is established, and the blocking control policy in BT. This time we will introduce the data interaction between the two sides when a connection is finally available, and also introduce another key policy controller piecepicker in BT. After choker selects to understand the blocking of a connection, upload. unchoke () will be executed, and send_unchoke () of the connection object will also be executed here. When the other end of the network receives the message, the corresponding singledownload. got_unchoke () will start processing. It checks its interested status again. If you are also interested in it, use _ request_more () to request data from the other party. _ Request_more () can be used as an indices parameter. this parameter is a list, meaning that the part of the number in this list is preferentially downloaded. If this parameter is set to none, it means you can do it yourself and find the right one. First, check your active_requests, that is, the requests that have been sent in the current connection. If too many requests have been sent (but no data is returned ), instead of sending a new request, the request is returned directly. Next, check the endgame. If you have already entered this stage, download (fix_download_endgame () as needed, and download the endgame in a special way in the final stage ). Next, we start to generate the request. First, check indices. If it is none, let piecepicker pick one. Otherwise, check the values in indices one by one, if the block of this number has (have [I]) and you want it again (do_ I _have_requests (I), then it is. We will analyze how piecepicker selects blocks later. What we know is that it has decided to download a block. Check interested and notify the other party if necessary. The following section describes the parameters that are constantly requested from the storagewrapper network. new_request continuously returns the relative offset and length of the block based on the ownership of a block on the hard disk. Here, we can see that there are three parameters for requests that require the actual data to be transmitted between peer-to-peer customers, namely, the number of blocks, the number of offsets, and the length. The length is determined by the parameters in the configuration file. It is usually a Server Load balancer, which can be downloaded once. Of course, the length of a piece is not necessarily an integer multiple of the slice, so the length of the last slice is shorter. However, these details have been processed in storagewrapper. After obtaining the request from storagewrapper, add it to your active_requests, and then let your connection object go to send_request (). Now we should be more clear about the meaning of active_requests and inactive_requests, that is, when storagewrapper prepares inactive_requests based on the actual situation and then sends a request in the singledownload object, gradually transfer them to their own active_requests. Under the two while loops, check active_requests, which means that if active_requests is null after all the above processes, what does it mean? It can only indicate that the other party does not have any data (or has never existed, but now it does not) that they are interested in. If they are still interested, call send_not_interested (), it means that I am no longer interested in you. Next, check the values in lost_interests. These are all what you wanted during the download process, but you don't want them now (mainly because you already have them ). Next, this for loop checks all the singledownload objects and tells them that some of them already exist. You don't need to go down any more, and some singledownload issues not_interested. Finally, check whether the game is in the endgame stage again. If yes, it will be processed according to the behavior of this stage. Now we can study the behavior of the piecepicker block selection policy controller. From the previous analysis, we know that each piecepicker corresponds to a _ singletorrent, which has gone through the following steps: first, initialize it, and then tell it to piecepicker (complete (I) based on the existing block. In the future, do not select it from the middle, in addition, when a singledownload object obtains the bitmap of the block ownership of the other party, it also needs to tell piecepicker (got_have (I), which means that someone has this block. Finally, when you need piecepicker to make a choice, you only need to call its next function, it needs a judgment function (_ want), and a sign (self. have. numfalse = 0), _ want function is such a function. When piecepicker selects a block, it will be checked to see if it really wants it. If not, piecepicker will reselect. The judgment criteria of the _ want () function are very simple, that is, what others have and want. Piecepicker initializes its internal variables. Here we need to explain the functions of these variables, so that we can more easily understand the following sections. Numpieces, total number of blocks. Interests is a list of blocks sorted by the number of owners. That is to say, it is a list. The 0th elements in the list are a list of all blocks that you are interested in but no one has, the 1st elements are the list of all blocks that interest you and only one person has. Pos_in_interests is the position of each part in the list represented by the corresponding element in interests. If a part, such as I, already exists, the value of pos_in_interests [I] is meaningless. The value of numinterests is the number of people (not including themselves) of a block. The preceding three variables maintain this relationship: If one I does not exist, then interests [numinterests [I] [pos_in_interests [I] = I. Have is a Boolean array, indicating that you already have the block. After initialization, it should be consistent with the actual situation in storagewrapper. Crosscount is an array of statistics, that is, how many blocks are owned by no one, and how many blocks are owned by one. Here, you can count one of them. Numgot, the number of blocks obtained. Scrambled, a sequence containing from 0 to numpieces-1, was randomly disrupted. Now let's take a look at piecepicker. complete: You have a block. First, you need to set the value in have. Then, you can check the number of people you have in numinterests and subtract one from the corresponding item in crosscount, then add one to the next item. If there is no next item, add one to the end. From this we can see that the crosscount array is gradually increasing. Then, it deletes the corresponding items in interests, because it is no longer in the scope of interest. Other lines of code are used to maintain the consistency of these variable values. Then try to delete this part from started and seedstarted (it doesn't matter if it doesn't exist, and you don't need to do anything ). Piecepicker. got_have, which is handled by someone else. First, we should keep crosscount consistent and then process the interests list. Call _ shift_over to transfer piece from one element in the interests list to another (and maintain the meaning consistency of values of other variables ). _ Shift_over is used to delete an element from the first list, insert it into the random position of the second element, and maintain the meaning of the value of pos_in_interests. Piecepicker. requested, which has been downloaded, will be called in singledownload. It only maintains two lists, started and seedstarted. Piecepicker. Next is the most important function provided by piecepicker. You can select one to download. The first principle of its choice is to first download it (returnchoice (bests) and its previous Code ). It checks the selected two arrays and selects an array based on whether the other side is a seed. Then, select all the expected numinterests in the array, check the numinterests, that is, the number of people who own the block, select the block with the least number of people, and put it into the bests, if there is a parallel element, it is added to bests. Therefore, After the end, the elements in bests are a list of all the chunks that are being downloaded and have the fewest users in the desired chunks, select a random return from the center. The second principle is that when you have less than a certain number of blocks, you can randomly select the desired block for download (the if block after the first stage ends ), therefore, it uses the scrambled list, and when the number of blocks that you own exceeds a certain value (config ['rarest _ first_cutoff ']), it implements the third-stage solution. The third principle is to first select the block with the least number of users to download. We can see that it starts to check the 1st elements in interests and selects the first block you want, no check is required for the 0th elements, because no part owned by anyone cannot be downloaded. We can see that its selection principle is simple but effective, downloading blocks with the least number of users gives priority to ensure that all blocks can be owned by as many people as possible in the shortest time, in other words, the copy rate of the content to be downloaded can be improved as soon as possible. This time, we analyzed how peer-to-peer users controlled the download policy during the download process. The next analysis will show the processing method after receiving the download request from the recipient.
