java.lang.Object
net.i2p.router.Tuner.BaseParam
net.i2p.router.Tuner.MaxStreamsParam
All Implemented Interfaces:
Tuner.TunableParam
Enclosing class:
Tuner

private class Tuner.MaxStreamsParamextends Tuner.BaseParam
Elastic, demand-following cap on concurrent streams shared by the streaming subsystem. Normally the streaming jar uses the user-configured i2p.streaming.maxConcurrentStreams (captured at init); this param pushes the override UP as legitimate demand or cap-refusals appear (so bursts on locally hosted services and the HTTP proxy are not dropped), and only steps it DOWN under true router starvation (job-lag + congestion). The effective cap in the streaming jar is min(configured, override), so the Tuner can never exceed a user ceiling. Malicious floods are handled at the refusal layer (SYN-rate gate + 24h auto-ban), not by crippling this cap.
  • Constructor Details

    • MaxStreamsParam

      MaxStreamsParam()
      Creates the parameter that caps concurrent streams.
  • Method Details

    • applyValue

      protected void applyValue(int value)
      Apply the tunable value to the streaming override.
      Specified by:
      applyValue in class Tuner.BaseParam
      Parameters:
      value - the tunable value to apply to router configuration
    • getRuntimeValue

      protected int getRuntimeValue()
      Read the current effective override the Tuner believes is in force.

      An override of 0 means the Tuner has never armed (the user's configured per-host maxConcurrent ceiling governs). The framework derives the persisted default from this value and force-applies it on the first tick, so reporting 0 here would clamp the default to _min (16) and silently cripple a healthy tracker to 16 concurrent streams. Instead we report the top of the working range (ConnectionOptions#getMaxMaxConcurrentStreams()): first tick then sees initial == runtime == ceiling and the Tuner stays unarmed until real saturation produces a target below the ceiling.

      Specified by:
      getRuntimeValue in class Tuner.BaseParam
      Returns:
      the effective cap to autotune against (0 stored override maps to ceiling)
    • getObservedStat

      protected double getObservedStat(RouterContext ctx)
      Description copied from class: Tuner.BaseParam
      Observed stat value used for autotuning.

      ctx is always this param's own context: Tuner takes a single RouterContext, hands the same instance to every BaseParam constructor, and both call sites pass Tuner.BaseParam._ctx. It was previously passed as null, which silently broke any implementation that used the argument instead of the field — a param reading a cross-reference stat then threw on every tuning cycle, was caught by the cycle handler, and never tuned at all, with nothing but a repeated WARN to show for it. Implementations may use either ctx or Tuner.BaseParam._ctx; both are the same object.

      Specified by:
      getObservedStat in class Tuner.BaseParam
      Parameters:
      ctx - router context, never null
      Returns:
      observed stat value for autotuning
    • computeTarget

      protected int computeTarget(double observed)
      Compute the elastic, demand-following stream ceiling.

      The cap is a headroom knob, not a DoS throttle: abuse is already shed at the refusal layer by the SYN-rate gate and the 24h auto-ban, so the ceiling's job is to keep legitimate streams flowing on locally hosted services and the HTTP proxy while the router stays responsive. Refusals and rising demand therefore push the ceiling UP toward the user's configured maxConcurrent ceiling (the streaming layer min(user, override) never lets us exceed it); only genuine latency/distress pulls it DOWN, and only one step at a time.

      Signals consumed (all registered live streaming / system stats):

      • stream.con.throttledHour/stream.con.throttledMinute — streams turned away by the "Dropped for conn limit" guard in the last window (event counts); firing = raise so bursts stop being refused.
      • stream.receiveActive — active-stream demand; the working cap is kept a few steps above it so bursts are absorbed rather than refused.
      • jobQueue.jobLag (ms) — CPU/system starvation; super-high lag is the only trigger for lowering the ceiling.
      • stream.rtxRatioBytes — retransmit overhead (per-mille bytes); raised with jobLag it confirms network/congestion distress.
      • stream.connectFailed — ms spent failing outbound connects; an early-to-middle latency signal that suppresses aggressive raises.
      Specified by:
      computeTarget in class Tuner.BaseParam
      Parameters:
      observed - the stream.receiveActive stat (active streams)
      Returns:
      the target ceiling for the streaming override