Tracker respone parsing (or: How standard is uTorrent?)

[Rechteck]

First: This is the best client I've ever used. (I didn't try Azureus yet... ^^)

If this post is misplaced please move me

I've progged a little PHP tracker (using MySQL) and it works fine (after approx. 4h to 5h coding) with uTorrent. But i've tried some other clients:

uTorrent (as said) => no problems

BitComet => no problems

Mainline (not the newest version) => continues to generate new peer_id's but works correctly

Some strange client I don't know the name of => says the trackers response is bad

I used these descriptions of the BitTorrent-protocol:

1 http://wiki.theory.org/BitTorrentSpecification which is atm offline

2 http://www.bittorrent.org/protocol.html

The response of my tracker is a normal HTTP 200 Response with various headers and a "Content-Type" of "text/plain" (see URL 1) containig the bencoded dictionary with the following keys:

"complete"

"incomplete"

"interval"

"min interval"

"peers" which has the keys

=> "ip"

=> "peer id"

=> "port"

[optional: "warning message"]

So my question is:

If uTorrent has no problems and the Mainline hasn't either can I claim my tracker to be "standard"?

And:

Can someone tell me how a "normal" tracker response looks like?

Thanks,

Rechteck

[DreadWingKnight]

I am working on posting a copy of the wiki.theory.org site over on one of my own servers.

Most current trackers use an alternate response format that has the "peers" value as a string with 6-byte peer information (4 byte IP, 2 byte port, network byte order) instead of the traditional (now legacy) format you're using.

[Rechteck]

So the content of the peers key should be like

l6:xxxxpp6:xxxxpp6:xxxxpp6:xxxxpp6:xxxxpp6:xxxxpp6:xxxxppe

?

("xxxx" meaning the ip and "pp" the port in network byte order)

Thank you for the fast reply!

Rechteck