client _handleResponse: allow string form of peer.ip

[astro]

BEP-3 states:

peers maps to a list of dictionaries corresponding to peers, each of which contains the keys peer id, ip, and port, which map to the peer's self-selected ID, IP address or dns name as a string, and port number, respectively.

The Theory.org Wiki agrees.

Is there any evidence of binary ip fields in the wild? Anyway, this code should support both.

[feross]

Is there any evidence of binary ip fields in the wild?

Are you referring to compact style responses, where peers are identified by 6 bytes (4 for IP and 2 for port)? That's the most common way that trackers return responses, since it's more efficient. See:

compact: Setting this to 1 indicates that the client accepts a compact response. The peers list is replaced by a peers string with 6 bytes per peer. The first four bytes are the host (in network byte order), the last two bytes are the port (again in network byte order). It should be noted that some trackers only support compact responses (for saving bandwidth) and either refuse requests without "compact=1" or simply send a compact response unless the request contains "compact=0" (in which case they will refuse the request.)

In fact, the biggest trackers just listed on udp and disable http since it's less efficient and pretty much all clients support udp these days. Still, I want there to be an http implementation in here since it's simpler and sometimes that's all you want/need. :)

[feross]

Wow, this was not doing what it was supposed to. This code is written to handle the case where the server sends back a compact response, pulling out each individual byte (like compact2string does), which is already handled above. We just need the ip.toString() part only.

[feross]

Fixed and published as 2.8.1.