Relive the Dreams

This month mainly engaged in two things, one is: Https://github.com/spin6lock/pydnsproxy, and the other is a BT client, used to search for magnetic links, download seeds, not well.

Pydnsproxy in last year's "sneak in the August" has been mentioned, but did not find a few obvious bugs. Before because the use of the queue is not correct, the initialization time, did not give a valid length, resulting in every time the use of the TCP link to plug in, will report the queue is full, and then be discarded. That is, every time a TCP query is basically a re-creation of the link. The cost of such a query can be very large, generally to 400-500ms. There was a problem with the previous caching method, which did not take into account the use of the handler class, and each time a request was received, Handler was instantiated once. In the previous version of the implementation, the cache is placed on the handler class, depending on the handler life cycle. Now because Tcp_handle is introduced as a method class, there is no problem, the next step should be to change the cache to a module variable.

In addition to bug fixes, is to add the Pydnsproxy HTTP DNS parsing, this way of advantage, can refer to the Penguin "Goose Factory Network" Global accurate traffic scheduling new ideas-httpdns service details. Simply put, the original DNS protocol is thrown away, directly provide an HTTP interface, give the domain name, return the corresponding IP. Additional parameters include request IP, which can resolve different IP addresses depending on the IP requested. For the time being, it can be used without interference from the wall. In the final analysis, what is needed is a pipe that can go smoothly outside the wall without interference. The concrete way of parsing, instead, is the second. Big companies like penguins have no problem maintaining a stable encryption channel, so by the way they use their httpdns to avoid poisoning pollution. Implementation of the time, have considered the problem of TCP connection pool, seemingly urllib2 not so advanced features, only URLLIB3 to provide Poolmanager. However, the test found that the Httpdns query is near the 20ms, although the 5ms than the cache is a little slower, but fully acceptable, this is worth observing.

The implementation of the BT client, organized well Ktable,kbucket,knode, seems to be almost. This time, it was a lot smoother to get Python to work, than the previous go version. There are two problems encountered, one is kbucket when split, how to split. This affects how long the program is running and how much memory is being consumed. The other is that when connecting with other clients, the problem of message error is now inclined to the other side of the implementation of the problem, because the other clients can be successfully answered. The code is not submitted because it is not finished.

Relive the Dreams