@zzzi2p, @anikey-from-i2p, @mpeter50, @Vort, @absolutep, @jiigen, @OvercookedBeef, @ValeZAA, @garret, @absolutep: Can you look this recent @arvidn PR?

@arvidn: Thanks for this first PR :)

Linked to:

• [I2P] [Feature Request] Support i2p_pex extension #7269
• Support for DHT and PEX with I2P #7408
• I2P Only Mode #7716
• implement i2p_pex, peer exchange support for i2p torrents #7831
• I2P Only Mode (depends on upstream libtorrent) qbittorrent/qBittorrent#19913

thanks for doing this.

max_peer_entries=100 is a little much, since it's 32 bytes per,
although you're quite unlikely to see 100 peers on an i2p torrent.
Recommend ~32. Snark is currently at 24, which is its
per-torrent peer limit.

Re: how you store destinations/hashes for peers
(your comments in torrent.cpp, not directly related to i2p_pex)
I do recommend you base64decode() full destinations when you get them
and store them in binary to save some space.
You may also wish to cache and save the 32 byte hash with it
to avoid the hasher256() call every time.

But I don't recommend you discard the destination and store the
hash only; to look up the full destination every time is
pretty inefficient. Java I2P does have a LRU lookup cache for hash-to-destination
and that mitigates the inefficiency for you somewhat, i2pd does also.
But for best performance you should consider adding your own cache.

nothing else jumped out at me, but I'm not a c++ guy;
good luck with the testing

max_peer_entries=100 is a little much, since it's 32 bytes per,
although you're quite unlikely to see 100 peers on an i2p torrent.
Recommend ~32. Snark is currently at 24, which is its
per-torrent peer limit.

Wouldn't it make sense to have a config option for it, to make the implementation more future proof? I think this development would make I2P an interesting service to look into for more people, and also more visible at all.
Or would it not matter anyway because of the low bandwith?

untested

Simplest test which came to mind is to start torrent without tracker and add one peer, which use client with well tested I2P PEX support.
I looked if it can be done with client_test and found only this possibility:

However, it looks like this feature is broken for i2p peers. Worth fixing I think.

Less reliable test was just adding random popular torrent and waiting until PEX support will appear in UI.

But there was no success with it: if I understand UI correctly, dark blue letter "p" in this case means PEX wasn't used.

I believe this works now, if anyone wants to give it a shot

to give it a shot

I saw white letter "p" in my test with 77a35ff:

Also log now contains messages like ==> I2P_PEX_FULL [ added: 1 msg_size: 67 ] and ==> I2P_PEX_DIFF [ dropped: 0 added: 5 msg_size: 67 ].
Is this enough to say "it works"?

@arvidn: Good job, thanks!

Linked to:

• [I2P] [Feature Request] Support i2p_pex extension #7269

Do not stop to add all improvements needed to have a perfect I2P support :)

I2P issues search:

• https://github.com/arvidn/libtorrent/issues?q=is%3Aissue+state%3Aopen+i2p+

Can you look for DHT?

• Support for DHT and PEX with I2P #7408

I2P BitTorrent details:

• https://geti2p.net/en/docs/applications/bittorrent