will be transparently unpacked with unpack200. Savings is about 60%.
Someday we will do this for suds, but we can do it for xpi2ps now.
* build: Add updater200 target
- Add js delete confirm
- Remove delete button for webapps
* i2psnark:
- Ignore a non-i2p tracker in a torrent rather than deleting
the torrent, thus "converting" a torrent to in-netowrk use
via the open trackers
- Add js delete confirm
- getFramedAveragePeerClockSkew() now returns a long (ms);
was a Long (s)
- Implement NTP-style clock slewing so the clock is adjusted
gradually
- Implement clock strata so we prefer better clocks
- Implement a timestamper in the transport so we will periodically
update the clock even if NTP is not working
This allows the router to converge the clock instead of simply
hoping the first connected peer is correct.
- Slow down NTP attempts after several consecutive failures
- 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.
