Pull inbound packets from the inbound receiver's queue, figure out what
peer session they belong to (if any), authenticate and decrypt them
with the appropriate keys, and push them to the appropriate handler.
Hmm, any guesses as to what this is? Used by the multitorrent functionality
in the PeerAcceptor to pick the right PeerCoordinator to accept the con for.
Manage the current state of the statistics
All the capabilities methods appear to be almost unused -
TunnelPeerSelector just looks for unreachables, and that's it?
If so, a lot of this can go away, including the array of 26 ArrayLists,
and a lot of synchronization on _capabilitiesByPeer.
Does the given peer send us bad replies - either invalid store messages
(expired, corrupt, etc) or unreachable replies (pointing towards routers
that don't exist).
Have seen peer tests (as Alice) get stuck (_currentTest != null)
so I've thrown some synchronizization on the methods;
don't know the root cause or whether this fixes it
static boolean isCongested(RouterContext ctx) {
float availableSend = ctx.bandwidthLimiter().getOutboundKBytesPerSecond()*1024 - ctx.bandwidthLimiter().getSendBps();
float availableRecv = ctx.bandwidthLimiter().getInboundKBytesPerSecond()*1024 - ctx.bandwidthLimiter().getReceiveBps();
// 6KBps is an arbitrary limit, but a wider search should be able to operate
// in that range without a problem
return ( (availableSend < 6*1024) || (availableRecv < 6*1024) );
}
Write out keys to disk when we get them and periodically read ones we don't know
about into memory, with newly read routers are also added to the routing table.
Prepare this hash's cache for xor values - very few hashes will need it,
so we don't want to waste the memory, and lazy initialization would incur
online overhead to verify the initialization.
Return true if there were messages remaining, and we should queue up
a delayed flush to clear them
NOTE: Unused here, see BatchedPreprocessor override, super is not called.
Since we are the inbound gateway, use the IV given to us as the first
16 bytes, ignore the 'prev' hop, and encrypt the message like every
other participant.
Expose a simple API for various router components to take note of
particular events that a peer enacts (sends us a message, agrees to
participate in a tunnel, etc).
Defines the minimum number of 'high capacity' peers that the organizer should
select when using the mean - if less than this many are available, select the
capacity by the median.
This maybe could be shorter than RepublishLeaseSetJob.REPUBLISH_LEASESET_TIMEOUT,
because we are sending direct, but unresponsive floodfills may take a while due to timeouts.
run in one of the TunnelGatewayPumper's threads, this pulls pending messages
off the prequeue, adds them to the queue and then tries to preprocess the queue,
scheduling a later delayed flush as necessary.