bittorrent | bittorrent client from scratch in rust | Stream Processing library

I know it might be possible that the trackers themselves may be ignoring the ip parâmeter. But I tested 50 different trackers and every one of them returns my IP address, not the custom one im trying to pass. Therefore I think the problem is in my implementation.

Almost all public/open trackers will not accept the IP parameter due to security problems. In principle they could do active verification (some tracker software supports that) but that's too expensive for open trackers. In practice only trackers with smaller user-bases will allow it, either gated by client authentication or by active verification.

I have implemented a bittorrent tracker client in python that successfully communicates with udp trackers and retrieves a peer list from them.

I would expect UDP trackers to be even less likely to support this parameter since the UDP tracker protocol is meant for high-load scenarios which are even less likely to afford any kind of verification.

For testing purposes you should look for some tracker software that explicitly supports the IP parameter (maybe a HTTP tracker meant for private torrent sites or at least an implementation not trimmed for high load scenarios) and run it locally. Once you have ensured that the server side supports it you can test the client properly.

The python socket documentation says that AF_INET6 addresses must be passed as a tuple of 4 values. If you pass a 2-tuple it'll be interpreted as AF_INET (IPv4) address.

Hm....

I removed the brackets around the StartupWMClass and it works. So it should not be [xxx]. It can only be xxx.

Looks like it is in iframe.

switch to iframe like this :

First, you need to change add the field named "orders" in Coin document.

It's like 2+2 that people will continue building up more advanced computers.

The primary cause for collision attacks is weaknesses in the hash function. Faster computers only provide very modest improvements as for every additional bit you to twice as much compute power. Even the still quite hypothetical general purpose quantum computers would only cut down collision resistance from N/2 to N/3.

Also, collision attacks are not a major threat to bittorrent. They could break certificate based systems built on top of bittorrent, e.g. where some 3rd entity vouches for the correctness of content described by a hash. But the primary use of hashes in bittorrent (integrity, i.e. getting bit-exact copies of whatever the initial seed published) is only vulnerable to preimage attacks.

and looking into new protocol, we can already see that its adoption is happening very slowly, it wouldn't be nicest thing if say in 2030 new collision occured, then developers will have to change this protocol again?

Bittorrent v2 specifies a meta version field in the info dictionary and requires that clients check for compatibility first before attempting to use the torrent, this will make future upgrades smaller and easier to roll out. But they are not specified in advance since we don't know which hashes or other security-related changes will be needed in the future. Specifying and negotiating more than one supported cryptographic primitive tends to be error-prone and increases implementation complexity.

The v2 magnet link already provides flexibility by adopting the multihash format.

V1 DHT is not compatible with V2 anyway.

That is incorrect.

The reason was very simple, and I should have understood it immediately. Power saving mode was enabled in the OS, which reduced the clock frequency of the CPU under low load. The moral is, always disable power saving when benchmarking!

Do they need to be honest and cooperate

More or less, yes.

or can the tracker somehow enforce the correct data?

Not in the general case of multiple colluding peers. In special cases of a single/few selfish downloaders it may be possible to detect them by cross-checking statistics from multiple peers but this is fragile and will require some fine-tuned heuristics to minimize false positives while still getting decent true positives.

It's basically a kludge, not something the protocol is designed for.

For the downloaded statistic a tracker could also participate in a swarm as a bittorrent peer and see the progress of a client based on have messages, but that doesn't work for upload and isn't all that reliable either because there's no guarantee that it could connect to all peers in a swarm to observe them.