I hate client management. Seriously. In ed2k module, it took literally months to get it working in a stable manner. Let's hope this won't be the case in Bittorrent module.
To get us started in that area, I drafted another short design doc, which among other things, addresses the client / torrent management issues. Read it
here.There are also some interesting new files in svn, for example:
hncore/bt/client.hhncore/bt/client.cpphncore/bt/manager.hhncore/bt/manager.cppYeye, I know, documentation is missing - I'll do that once the code stabilizes a bit.Basically, I implemented all of the protocol Client <-> Client packets, along with client management and messages passing. Next up, we need to start adding protocol flow logic - and that's tricky at best. Bittorrent protocol, while being very small itself (as you can see in client.cpp - that's all of the protocol, implemented in under 300 lines of code), the packet flow logic on the other hand is very complex. We'll be testing, tuning and improving that one for weeks to come.
However, the most current issue is that I can't get my handshake packet right. In all protocol specs (
official,
unofficial), it says "1 byte of value "19", string "BitTorrent Protocol", 8 reserved bytes, 20 bytes info_hash and 20 bytes peer-id". I event went to look inside libtorrent code, and it's same in there. I'm sending this:
00000000 13 42 69 74 54 6f 72 72 65 6e 74 20 70 72 6f 74 |.BitTorrent.prot|
00000010 6f 63 6f 6c 00 00 00 00 00 00 00 00 00 00 e8 17 |ocol............|
00000020 b8 80 24 a2 58 b9 77 7f c1 98 fc 0e 75 a1 49 60 |..$.X.w.....u.I`|
00000030 0d c2 48 4e 30 31 32 30 39 38 33 34 33 38 30 37 |..HN012098343807|
00000040 30 32 35 31 39 37 |025197|
And all clients just drop the connection. Got some extra info from Azureus - it basically seems to recognize the handshake, and even sends response, but then bails out and cuts the connection with error "unexpected end of stream". Am I supposed to send something else right after handshake? *duh*.
Madcat, ZzZz
