CODEWITHSUNDEEP
bittorrentdhttorrent
orraz1
orraz1

Reputation: 43

trying to understand the flow chart of the extended message protocol as mentioned in bep 10

I was reading bep 10 and I'm trying to fit the article to the packets I've captured. essentially through what I understand a client (the initiator) would begin by sending a normal handshake message (as specified in bep 3). Then the receiver will check if the initiator supports the extended protocol, if he does he'll send the extensions he supports using an m dictionary. The initiator then responds with his own m dictionary with his own extensions which matches the responders m dictionary. How correct is this? Is the only one who can send the extended handshake message first or can the initiator begin with it?

As mentioned above I've read bep 9,10, and 3 (only 10 and 3 matter for this) and I caught packets of extended messages.

Upvotes: 0

Views: 57

Answers (1)

the8472
the8472

Reputation: 43125

The extended message support is negotiated in via reserved bits. Once a peer learns that both sides support the extension protocol they can send the extended handshake. Since the send and receive halves of TCP do not operate in lockstep there isn't really any ordering between the extended handshakes, although it will be the receiver who'll usually learn about mutual support a bit sooner and so might end up sending the extended handshake sooner, but they're not required to.

The initiator then responds with his own m dictionary with his own extensions which matches the responders m dictionary.

No, they're not required to match. They can simply advertise what they can receive. In principle it can make sense for a client to receive some extensions but not send them or vice versa.

Upvotes: 1

Related Questions