from three years ago,
to match current version of Proposal 160.
Revert back to standard BEP 15 from "fast mode".
Add TrackerClient and I2PSnarkUtil changes.
Datagram2/3 hooked in.
Variable lifetime handled.
Co-authored-by: zzz <zzz@i2pmail.org>
Reviewed-on: http://git.idk.i2p/I2P_Developers/i2p.i2p/pulls/504
Reviewed-by: idk <idki2p@mail.i2p>
Ancient msgfmt doesn't know about generics.
This change allows devs to set javac.compilerargs=-Xlint:unchecked
in override.properties without getting an
overwhelming number of false positives from the bundles.
If msgfmt ever adds a --java5 option, we can remove this,
but it's been almost 20 years.
For the same reason, while the sed script is fragile,
seems unlikely msgfmt will change the output without a new option.
If they do, we'll fix it then.
Hopefully fixes rare case where torrents get stuck.
Tested that it doesn't break anything, but was never able to reproduce the issue.
As reported in torrent at http://tracker2.postman.i2p/index.php?view=TorrentDetail&id=85798
Fix adapted and greatly simplified from source code included in that torrent.
Apparently from old trac ticket #691.
Credit: smtorrents
Also:
- Fix place where removePeerFromPieces() was being called twice,
once directly and once from disconnect(true).
- Fix javadoc for Peer.disconnect()
- Fix log typo
- Add comments
Description from OP of that torrent:
This update now finally fixes the decades old ticket number 691 which prevents torrents to complete from time to time. The bug manifests itself by keeping a couple of outstanding pieces (> 8, so we never get into the endgame) that are marked as requested from a peerID, with a corresponding peer that has long gone. Those pieces are never requested from any other peer. There are consequently more peerIDs than peers connected.
The only place in code, where peers and peer IDs are mixed up, is a reconnect logic that tries to reuse an existing connection while keeping outstanding requests from the old connection, when the other end tries to reconnect.
Keeping old requests is faulty by itself because someone reconnecting to us will definitely have dropped our previous requests, so we must do the same. The fix now always drops previous connections along with all outstanding requests.
Tweaks to previous MR:
_ Use new constructor for edit CLI
- Javadocs for new constructor
- Add new_url_list param to new constructor
- Set creation date if unset
to improve search for non-ASCII strings.
Normalize both search and searched strings to NFKD when searching.
NFKD is best because it is more efficient than NFKC and it removes
formatting distinctions. This results in the best fuzzy matching.
This was just a display issue; actual internal limit was correct.
Snark limit will continue to be capped at about 60% of the router limit
to account for overhead.
zzz