Jump to content

extended messages and ut_pex - too few messages from peers


Recommended Posts

Hi, I am implementing very simple client to understand BitTorrent protocol better. Right now my client works like this:

- Open connection to peer(from tracker's peer-list)

- Send handshake with extended bit set

- Read peer's handshake back and send extended message immediately after getting last byte of handshake, I am using following keys in message: m = {ut_pex = 1}, v = "appname", e = 0, p = port

- Read extended handshake from peer and drop connections to peers, which doesn't support ut_pex

- Listen for incoming messages(my client doesn't send anything from this point)

When I start to listen for incoming messages I have around 150 out of 500 peers connected. I can see lot's of "bitfield" and "having" messages coming to me, but there are only 3-4 extended(20) messages in about 10 minutes. Is it ok, or should I get more ut_pex messages? Can this be related to using custom app name, or not using some values of extended message? Maybe peers expect me to send anything?

I am not beside NAT and I can bdecode extended messages just fine, so I think there are no low-level errors in my app, but my high-level logic can be wrong.

Link to comment
Share on other sites

Hi, thx for reply.

I was able to fix this problem, in my case it was a simple bug. I was expecting data from socket to be shorter than I want, but didn't expect it to have more than one message.

As for ut_pex, this is utorrent extension(it's ut_ for a reason :) ) and any modern version of utorrent will send it, helping any client that support ut_pex to get more peers.

Link to comment
Share on other sites


This topic is now archived and is closed to further replies.

  • Create New...