- 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.
- Store and report UDP clock skews even for large values, so
a badly skewed local clock will be reported to the console
- Don't shitlist for NTCP clock skew if we don't know what time it is
- If NTP hasn't worked yet, have NTCP or SSU update the clock one time
- Include failed clock skew in NTCP skew vector if there aren't many connections
- Don't include NTCP clock skews for non-established connections
- Fix framed clock skew frame size
- Report framed clock skew even if for only one peer, if NTP hasn't worked yet
- Don't log RRD errors after clock adjustment
- Reduce min skew for console warning to 30s (was 45s)
- More Java 5 cleanups
- 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
on a stream... AKA setting keepalive. This should fix the stuck NTCP
issue that has been bothing zzz for years.
* Set keepalive on BOB connections too, since this will assist closing
the connections in the event of a crash on a client.
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.
