Zur Navigation springen Zur Suche springen
BitTorrent protocol analysis[Bearbeiten]
- Description of the official protocol: http://wiki.theory.org/BitTorrentSpecification
Description of the 'no_peer_id' and 'compact' enhancements: http://wiki.theory.org/BitTorrentTrackerExtensions
Tracker HTTP Protocol[Bearbeiten]
- Example GET queries sent to the tracker:
Request: problematic fields[Bearbeiten]
- Description: Unique ID for the client, generated by the client at startup.
- Content: 20-byte string. This is allowed to be any value, and may be binary data. There are currently no guidelines for generating this peer ID. However, one may rightly presume that it must at least be unique for your local machine, thus should probably incorporate things like process ID and perhaps a timestamp recorded at startup. The official client (version 3.4.2) sends: 'M' + versionnr + enough filling '-' + last 12 chars of hex(sha(timestamp + ' ' + pid)) Details for other clients are on: http://wiki.theory.org/BitTorrentSpecification#peer_id
- Privacy leaks: There seem to be no danger this giving anything important away.
- Usage: For I2P-BT I suggest to use a custom version identified, but otherwise keep the peerid the same.
- File: BitTorrent/download.py line 191
- Description: The port number that the client is listening on.
- Content: Integer. Ports reserved for BitTorrent are typically 6881-6889.
- Privacy leaks: Because I2P doesn't use a port for a destination, port 6881 will always be chosen; even if there are other normal bittorrent clients running. So this field can be kept.
- Usage: The client tries to bind to ports in the range 6881-6999. If a bind fails the next one is used. Because on I2P a bind failure will not be the result of a port being used, it is useless to try to bind 119 times. Thus it is better to only use 6881 and let the tracker enforce this.
- File: BitTorrent/download.py line 235
- Description: (Optional) The true IP address of the client machine
- Content: String, in dotted quad format or rfc3513 defined hexed IPv6 address. Notes: In general this parameter is not necessary as the address of the client can be determined from the IP address from which the HTTP request came. The parameter is only needed in the case where the IP address that the request came in on is not the IP address of the client. This happens if the client is communicating to the tracker through a proxy (or a transparent web proxy/cache.) It also is necessary when both the client and the tracker are on the same local side of a NAT gateway. The reason for this is that otherwise the tracker would give out the internal (RFC1918) address of the client, which is not routeable. Therefore the client must explicitly state its (external, routeable) IP address to be given out to external peers. Various trackers treat this parameter differently. Some only honor it only if the IP address that the request came in on is in RFC1918 space. Others honor it unconditionally, while others ignore it completely. In case of IPv6 address (e.g.: 2001:db8:1:2::100) it indicates only that client can communicate via IPv6.
- Privacy leaks: Obviously this field should not be ignored; it will give away your IP.
- Usage: As previously explored, this field can set best to the destination of your tunnel. While binary content is allowed in the tracker, it is easier to use the Base64 value. Make this field required and let the tracker enforce it to be correct Base64.
- File: BitTorrent/download.py line 278
- Description: The 'compact mode' enhancement lets the tracker return a shorter list of peer information.
- Content: Binary encoded string with IP and port information.
- Privacy leaks: No privacy leak after above changes.
- Usage: This mode should be disabled, because it is not compatible with I2P's Base64 destinations.
- File: BitTorrent/Rerequester.py line 75
Response: problematic keys[Bearbeiten]
- Description: List of contact info for peers.
- Content: The value is a list of dictionaries, each with the following keys:
- peer id: peer's self-selected ID, as described above for the tracker request (string)
- ip: peer's IP address (either IPv6 or IPv4) or DNS name (string)
- port: peer's port number (integer)
- Privacy leaks: After the changes proposed earlier, the ip field should contain the destination and can be safely kept. Port can be ignored
- Usage: The client should support a string containing a Base64 encoded destination on the place of an IP.
Peer wire protocol[Bearbeiten]
- During the handshake the peer_id is sent. This 20 byte string is used as an unique ID for the client. This is the same peer_id that is transmitted in tracker requests.