BT source code learning experience (12): client source code analysis (from the beginning to the connection establishment stage) Author: Wolfenstein this time the recovery starts according to the process description, that is, from multitorrent. start_torrent function execution starts. Through the previous analysis, we know that when multitorrent. start_torrent is called, a new download task starts. This function itself is very simple, that is, creating (and returning) A new _ singletorrent object, and then letting its start_download method start scheduling. The start_download function looks a bit strange at the beginning, but it is actually a trick designed by the author. The yield keyword in Python allows a function to return a value, but its internal execution status is still saved, so that the function will continue to be executed from there when the function is called next time. Such as it = self. _ start_download (* ARGs, ** kwargs) is used to determine an iterator. Note that when executing this sentence, _ start_download is not executed. To execute a function containing the yield keyword, you only need to call it repeatedly. next (), which will return the value of yield each time. When the function is executed to the end, a stopiteration exception will be thrown. By capturing this exception, you can know the function and the execution is complete. In start_download, a function is assigned to _ contfunc and executed once. The actual content of this function is to start to execute _ start_download. Why is it so costly? The purpose of this function is to split a thread at an appropriate time. So far, only one main thread is running in the program. Continue to the _ start_download function. Sort out an actual file list based on the Object List of metadata and the address saved to the hard disk, and store them directly. Create a new storage object. You can use the zip function to obtain the list of file names and size tuples. The function is based on the first parameter (list type) obtain the first element, and then form a tuples with the first element of the second parameter. Then, the first parameter and the second element of the second parameter form a tuple, finally, it becomes a list. Then perform a "quick recovery" file check. Next, we noticed that the hashcheck function was created by creating a new thread and then letting it start running. Next, yieldnone. Note that this sentence has actually been returned. The hashcheck function will be executed in a new thread. Let's take a look at what is done in the hashcheck function. It mainly creates a storagewrapper class, it has determined the content on the hard disk during initialization. Then, it executes _ contfunc ()! Yes, the result of executing it is to continue the execution from the part after yieldnone, but it is already in another thread. Next, create a choker and some speed measuring devices. Create a piecepicker. After initialization, you need to tell the piecepicker which blocks already have (piecepicker. Complete) and which blocks are already part (piecepicker. requested ). Next, we will create a downloader object. However, for upload, we only define a function make_upload, which can generate an upload object at any time. Then create an encoder object. Note that it uses downloader and make_upload as parameters. In terms of structure, they are bound together. Next, use add_torrent to bind a seed file (with infohash as the keyword) with its encoder. In this way, when receiving connections from other peer clients, you will be able to know which seed file the recipient wants to download. Finally, create the rerequester and downloaderfeedback objects. Finally, run rerequester. begin, start it, let it begin to interact with the tracking server, and then you can call the started function of the feedback interface, which means that we have started, as a result, the feedback interface needs to be displayed on the graphic interface or text interface. Rerequester. Its role is to send peer-to-peer customer information to the tracing server. The previous analysis of the tracing server code has a basic understanding of the communication protocols between the client and the tracing server. We call the process of making an HTTP request and obtaining the response data of the server as an announce. The rerequester's begin function can ensure that you check the request every 60 seconds. Let's take a look at _ Check what to do: first of all to ensure that the interval between the two releases can not be too short, but also according to their own peerid make URL (_ makeurl: http://xxx.xxxtracker.xxx: xxxx/announce? Info_hash = XXXX & peer_id = XXXX & Port = XXXX & Key = XXXX), call _ announce for a release based on different situations. The parameter value for _ announce indicates the value of the 'event' parameter. The significance of these 'event' can be seen in the code analysis of the Tracking Server, which determines the different stages of download. _ Announce is often called because peer-to-peer information is also frequently required. Its main task is to further process the URL, calculate the URL used for the current release, save it in S, and then start publishing with a new thread, the reason for using the new thread is that you do not want the network blocking of the tracing server to affect the execution of other parts of the program. _ Rerequest can basically send this HTTP request. Of course, part of the code at the beginning of rerequest is to exclude the situation where some of its external IP addresses are different from the actual IP addresses. Request is a module in zurllib, which can easily send an HTTP request and obtain the returned information. Determine whether to call _ postrequest based on the error. The error here is only because of an HTTP request error, such as a network problem. The tracking server may return some other error information, which can be seen in _ postrequest. _ Postrequest first checks whether an error message exists and then performs bdecode on the data. We are familiar with this process. Next, use check_peers to check whether this is a standard peer-to-peer customer information data. check_peers is defined in BitTorrent/btformats. py, and there are other functions to check the information format. The next step is to check whether there is a keyword 'failurereason 'in R. If yes, it means that there is no problem with the network of the tracing server, but the tracing server returns other causes of failure, this is still a case of failure. The following is to parse the data with the keyword 'peers' in R. The data transmitted from this Part may be a compact string or a dictionary, we can see this in the code analysis of the Tracking Server. Finally, you can call the connect function to try to establish a connection with peer-to-peer customers one by one. The connect function is actually encoder. start_connection. Next time, you can analyze the communication protocols between two peer clients.
