- Randomize Build Message expiration to make it harder to guess hop position
- Save expired tunnel build configs for a while, so that we will still use the tunnel
and update peer stats if the reply comes in late
- Don't update our own profile for Tunnel Build Replies
- Add getRecordCount() to TunnelBuildMessage and TunnelBuildReplyMessage
so they can be extended.
- New I2NP Messages VariableTunnelBuildMessage and VariableTunnelBuildReplyMessage,
which contain the number of request slots in them.
- Convert all static assumptions of 8 slots to getRecordCount()
- Use the new VTBM if all hops in the tunnel and the OBEP or IBGW of the reply tunnel
support it, and the tunnel is 4 hops or shorter.
- Reply to a VTBM with a VTBRM of the same size
- Make BuildReplyHandler static
- Convert the currentlyBuilding List to a ConcurrentHashMap to speed reply lookups
and eliminate a global lock; don't put fallback tunnels in there
- Add new tunnel.corruptBuildReply stat
- Various cleanups and javadoc
Tested as compatible with current network, new messages untested.
- Enable multiple parallel job runners much sooner to speed startup
- Rearrange the startup order to get the long jobs started sooner
- Don't allow the netDb readin job to clog the job queue
Since the earliest date functions as a version number,
this will force the floodfill to flood each new version;
otherwise it won't if the earliest time hasn't changed.
- Do LS stores and verifies through client tunnels
to prevent correlation by the OBEP or FF
- Encrypt LS stores to prevent snooping by the OBEP
- Encrypt LS and RI verifies to prevent snooping by the OBEP
- Extend verify delay and timeout
- Reenable RI verifies
- Disallow simultaneous verifies for the same key
- Don't resend on verify timeout; try a different peer instead
- Adjust ff selection criteria
