Lua what's new in BitTorrent DHT?

Some time ago I wrote for Shareaza an external DHT Tracker on Lua ( GitHub ). For Shareaza, this is a regular local tracker, but in essence it is a BitTorrent DHT client that allows it to download torrents from magnet links without a tracker.

So, while the client is working, it catches packets with unknown fields and saves it for further analysis (if the option is enabled).

So, what's new in BitTorrent DHT. (Standard fields are cleared but left for clarity):

{
	v = "UTct",
	q = "vote",
	a = {
		target = "",
		vote = 0,
		token = "",
		id = ""
	},
	y = "q",
	t = ""
}

We look what's new:

• v = “UTct” - These are two letters of the client ID (in this case uTorrent) and the version is 2 bytes (63 74).
• q = "vote" - Judging by the name, it is "Vote".
• vote = 0 - Well this is apparently a rating.

Everything else is the same as in the announce_peer package, although port is missing, but it is obviously not needed here.

Pulling through a bunch of votes, we come across another interesting package:

{
	v = "UTdS",
	q = "announce_peer",
	a = {
		name = "File Name.avi",
		info_hash = "",
		port = 1,
		id = "",
		token = ""
	},
	y = "q",
	t = ""
}

The usual announce_peer with a plus in the form of a torrent name (see a.name). Apparently for a search engine or to display the name before receiving info.

We look further and find:

{
	v = "Az \ 5H",
	q = "announce_peer",
	a = {
		seed = 0,
		info_hash = "",
		port = 1,
		token = "",
		id = ""
	},
	y = "q",
	t = ""
}

By customer ID, we understand that we are already dealing with Azureus (judging by the Wiki, this is already Vuze). Also announced_peer came to us with a plus in the form of a seed field, which is set to 0. Apparently, this feast is not a seed, says KO.

And again, Azureus:

{
	v = "AZ00",
	q = "get_peers",
	a = {
		scrape = 1,
		want = {
			"n4"
		},
		info_hash = "",
		id = ""
	},
	y = "q",
	t = ""
}

We see scrape and want. Apparently this is an analogue of the Scrape request to the tracker. Want is a list and contains the value "n4". This field has long flickered, and I learned a little about it. N4 are IPv4 addresses and N6, respectively, IPv6 addresses can be simultaneously.

This is our catch today. It remains to add about what has already been added to the packet filter:

{
	r = {
		ip = "\ 0 \ 0 \ 0 \ 0",
		nodes2 = {}
	}
	y = "r"
}

The answers may contain an additional ip field. The investigation revealed that this is your own ip.
nodes2 - list of ipv6 nodes as far as I remember. Since my provider is still on ipv4, this is a question I have not worked through deeply.

Of course, a lot of new things appeared, and in connection with this I got an idea to give the opportunity to ask help from the client who sent the unknown package.

It looks like this:

Request

{
	t = "",
	y = "q",
	q = "help",
	a = {
		path = {"q", "help"} - I think the list is better than the line. There used to be a line in which field names were separated by a dot.
	}
}

In this case, this is a help request for q = help.

And the following answer should come to him:

{
	t = "",
	y = "r",
	r = {  
		help = 		
[= [
q = [help, ping, find_node, get_peers, announce_peer]
help - Micro help about new parameter of dht packet.
 a.path (query packet) - path to new parameter
 r.help (responce packet) - help about new parameter
more: http://forum.bittorrent.org/viewtopic.php?pid=2134
other see on http://bittorrent.org/beps/bep_0005.html
] =]
	}
}

Perhaps additional links are better in a separate list.

Well. Those interested in this topic google details, write comments.

By the way forum.bittorrent.org does not work for me. And there innovations of BitTorrent clients were discussed just.

PS For Peer-to-Peer karma is not enough.
PPS Thanks for the karma. Moved.