Tracker server source code analysis: Total
Author: Ma Ying-jeou
Date: 2004-5-29
The Tracker server is the role that must be in BT download. A Bt Client is in the process of downloading and downloading, communicating with the Tracker server to report its own information and get information on downloading Client. This communication is carried out through the HTTP protocol, and is also known as the Tracker HTTP protocol, which is like this:
Client sends a HTTP GET request to Tracker, put it in the parameters of GET; this request is righteous: I am XXX (a unique id), I want to download YYY file, my IP is AAA, I used the port of which is BBB. . .
Tracker maintains all the downloaders' information, after it receives a request, first record the other party's information (if you have already recorded case, check if you need to update), then part (not all, according to settings) The request of the parameter has been downloaded to download the same file (a Tracker server may also maintain the downloader of the downloader of the multiple files) to the other party.
Client After receiving the Tracker's response, you can get information about other downloaders, then it can establish a connection with other downloaders based on this information, download file snaps from them.
Details of the communication protocol between Client and Trackers have been given in the BT Protocol Specification, which is no longer repeated. Here we specifically analyze the implementation details of the Tracker server.
Where do you start?
To create a Tracker server, just run the bttrack.py program, it requires a parameter, which is -dfile, which specifies the file that saves the download information. Bttrack.py calls the track () function in TRACK.PY. Therefore, we track the track.py to see the track () function.
TRACK.PY :TRACK ()
This function first checks the parameters of the command line; then save these parameters to the Config dictionary. All tool programs in the BT have similar processing methods.
The next code:
R = Rawserver (Event (), config ['Timeout_Check_Interval'], config ['socket_timeout'])
T = Tracker (Config, R)
R.Bind (config ['port'], config ['bind'], true)
R.Listen_ForeVer (httphandler (t.get, config ['min_time_between_log_flushes']))
T.SAVE_DFILE ()
The first is to create a Rawserver object, which is a server object that will implement some of the details of a web server. Not only the Tracker server uses RawServer, we can also see later. Since each Client side needs to provide download services to other clients, it is also a server, the implementation of the client, which also uses Rawserver, this, Rawserver code Got reuse. About the detailed implementation of Rawserver, analyzes in the following subsections.
Then you create a Tracker object.
Then let the RawServer are bound to the specified port (transferred through the command line). Finally, call the RawServer :: Listen_Forever () function, so that the server is running.
Finally, after the server ends the run, call TRACKER :: Save_dfile () to save the download information. In this way, once the server is run again, it can restore the current state.
Other Information:
1, the distribution of BT source code:
After the source code of the BT is expanded, you can see some Python programs, there are some explanations, etc., there is a bittorrent directory. These Python programs are actually some gadgets, such as making metafile btmakemetafile.py, running the bttrack.py of the Tracker server, running BtDownloadHeadless.py at the BT Client end. In these programs, the implementation of some of the Python classes used is placed under the subdirectory bittorrent. Our analysis works, usually starting with tool programs, such as bttrack.py, and with the analysis of the analysis, the focus is the code under the BitTorNet subdirectory.
BT Authors BRAM Cohen talks about how to develop a maintenance code (http://www.advogato.org/Article/258.html), which mentioned is to develop some gadgets to simplify work, I think this source structure of BT is the embodiment of the author's thinking.
2, we see that Python and our C / C different places in contact with us are its function when defined, do not specify parameter types. Since this, then when the function is called, you can pass any type of parameters. For example, such a function:
DEF foo (arg):
Print Type (Arg)
You can call this:
A = 100
B = "Hello World"
Foo (a)
Foo (b)
The output result is:
This is because when foo () is called for the first time, it is transmitted an integer type, while the second time is called, it is a string type.
This parameter has a dynamic type characteristic, and it is not available in conventional languages such as C / C . This is also a reason why Python is called dynamic language. C advanced characteristic template, although the parameter type can be dynamically, but it is easy to easily and convenient.
