- All Implemented Interfaces:
Job
- Enclosing class:
TunnelPoolManager
Selection samples a bounded slice of the high-capacity tier (ProfileOrganizer.maxCandidateSample(int, int)), so an unconnectable peer can sit in that tier indefinitely and be drawn into builds that fail at the first hop. Nothing else records reachability cheaply: send-failure strikes only accumulate on tunnels already in use, and a peer that never answers produces no reply to blame. This job supplies that missing signal by pre-connecting to a bounded slice and letting TunnelPeerSelector.PreConnectFailJob demote whatever fails.
Sweep, pause, sweep: each pass probes at most PROBE_BATCH peers and then waits PROBE_INTERVAL, so the whole tier is covered over several passes without a burst of outbound traffic. Only peers we are not already talking to are probed — a peer with recent successful traffic has fresh evidence already, and probing it would spend the budget re-confirming what we know.
Field Summary
FieldsModifier and TypeFieldDescription(package private) static final longWall clock wanted for one pass over the whole tier, while young.(package private) static final longUptime before which the sweep runs at its faster cadence.(package private) static final longCeiling on the gap between passes, so coverage never stops refreshing.(package private) static final longFloor on the gap between passes regardless of band size.(package private) static final intPeers probed per pass.(package private) static final intPeers per pass while young, when nothing has been measured yet.(package private) static final intPeers per pass once the fast window has passed.(package private) static final longDelay between passes, giving the probed slice time to be used or fail.(package private) static final longA peer we have built through this recently needs no probe.(package private) static final longWall clock wanted for one pass once steady.Constructor Summary
ConstructorsConstructorDescriptionFastTierProbeJob(RouterContext ctx, TunnelPoolManager mgr) Probe whether fast-tier peers are reachable, shortly after startup.Method Summary
Modifier and TypeMethodDescriptiongetName()Descriptive name of the task.(package private) static booleanisRecentlyActive(RouterContext ctx, Hash peer, long now) Whether this peer has traffic recent enough that probing adds nothing.(package private) static intprobeBatchFor(long uptimeMs) Peers to probe per pass, based on how much of the profile is still unmeasured.(package private) static longprobeIntervalFor(long uptimeMs, int bandSize, int batch) Gap between passes, derived from the tier size so a full sweep takes a predictable wall-clock time whatever the population.voidrunJob()Actually perform the task.Methods inherited from class JobImpl
dropped, getContext, getJobId, getMadeReadyOn, getTiming, madeReady, requeue, toStringModifier and TypeMethodDescriptionvoiddropped()Default implementation does nothing.final RouterContextThe router context that this job belongs to.longgetJobId()The unique job ID for this job.longThe timestamp when this job was last made ready for execution.The timing object for this job.voidmadeReady(long now) For JobQueue only, not for external use.protected voidrequeue(long delayMs) Requeue this job to run after the specified delay.toString()
Field Details
PROBE_BATCH
static final int PROBE_BATCHPeers probed per pass. Bounds the burst so a pass is not a flood.- See Also:
PROBE_INTERVAL
static final long PROBE_INTERVALDelay between passes, giving the probed slice time to be used or fail.- See Also:
RECENTLY_ACTIVE_MS
static final long RECENTLY_ACTIVE_MSA peer we have built through this recently needs no probe.Deliberately generous, and comfortably wider than one build cycle: a peer we are already successfully sending through is confirmed for as long as that keeps being true, so the only peers worth spending budget on are the idle ones the sweep exists to find. A narrow window would re-probe the peers working hardest, which is where the budget is least useful.
Widening this constant reduces coverage. It widens the skip set, not the probe set — so it is only safe because the test below keys on our own send successes rather than on incidental inbound traffic.
- See Also:
FAST_WINDOW_MS
static final long FAST_WINDOW_MSUptime before which the sweep runs at its faster cadence.- See Also:
PROBE_BATCH_FAST
static final int PROBE_BATCH_FASTPeers per pass while young, when nothing has been measured yet.- See Also:
PROBE_BATCH_STEADY
static final int PROBE_BATCH_STEADYPeers per pass once the fast window has passed.- See Also:
FAST_PASS_TARGET_MS
static final long FAST_PASS_TARGET_MSWall clock wanted for one pass over the whole tier, while young.A young router has measured nothing, so the tier is unpopulated with first-hop latency and nothing can be judged until it is covered. Twenty minutes reaches a full sweep quickly without turning the probe into a sustained flood: probes carry establishment cost and the failures that come with it, and those failures are what demote peers.
- See Also:
STEADY_PASS_TARGET_MS
static final long STEADY_PASS_TARGET_MSWall clock wanted for one pass once steady. Matches the original cadence.- See Also:
MIN_PROBE_INTERVAL_MS
static final long MIN_PROBE_INTERVAL_MSFloor on the gap between passes regardless of band size.- See Also:
MAX_PROBE_INTERVAL_MS
static final long MAX_PROBE_INTERVAL_MSCeiling on the gap between passes, so coverage never stops refreshing.- See Also:
Constructor Details
FastTierProbeJob
FastTierProbeJob(RouterContext ctx, TunnelPoolManager mgr) Probe whether fast-tier peers are reachable, shortly after startup.- Parameters:
ctx- the router contextmgr- the pool manager this job reports reachability to
Method Details
probeBatchFor
static int probeBatchFor(long uptimeMs) Peers to probe per pass, based on how much of the profile is still unmeasured.- Parameters:
uptimeMs- router uptime in ms- Returns:
- the batch size for the next pass
probeIntervalFor
static long probeIntervalFor(long uptimeMs, int bandSize, int batch) Gap between passes, derived from the tier size so a full sweep takes a predictable wall-clock time whatever the population.Computing the interval from
targetPass * batch / bandSizerather than fixing it means the same cadence holds at 200 peers or 2000: a small tier is not over-probed and a large one is not starved. Clamped so a very small or very large band cannot produce an absurd interval.- Parameters:
uptimeMs- router uptime in msbandSize- how many peers are selectable, non-negativebatch- peers per pass, must be positive- Returns:
- the delay until the next pass, in ms
getName
runJob
public void runJob()Description copied from interface:JobActually perform the task. This call blocks until the Job is complete.isRecentlyActive
Whether this peer has traffic recent enough that probing adds nothing.Only our own successful sends count. Inbound hearing is deliberately ignored:
PeerProfile.getLastHeardFrom()advances on DHT replies, explore traffic and transit acknowledgments, so it marks most of the tier as recently active without ever showing the peer works as a first hop. Keying on it made a 2 minute window behave like a much longer one and left a pass probing 33 peers out of a 128 budget.- Parameters:
ctx- the router contextpeer- the peer to testnow- current time in ms- Returns:
- true if recent traffic means we should skip probing