java.lang.Object
net.i2p.router.tunnel.pool.BuildRequestor
public abstract class BuildRequestorextends Object
Utility class for creating and dispatching tunnel build request messages.

This class handles:

  • Preparation of tunnel hop IDs
  • Selection of paired or exploratory tunnels for replies
  • Construction of TunnelBuildMessage, including legacy and new-style (Short/Variable) formats
  • Garlic encryption for inbound builds
  • Timeout and failure handling

Paired tunnels are always used (as of 0.9.50+) to improve client isolation and prevent correlation across tunnel pools.

  • Field Details

  • Method Details

    • setRequestTimeout

      public static void setRequestTimeout(int ms)
      Set the build request timeout (called by Tuner).
      Parameters:
      ms - the build request timeout in ms

    • setFirstHopTimeout

      public static void setFirstHopTimeout(int ms)
      Set the first-hop timeout (called by Tuner).
      Parameters:
      ms - the first-hop timeout in ms

    • getRequestTimeout

      public static int getRequestTimeout(RouterContext ctx)
      How long we wait for a reply before trying a different pool/peers. Adaptive mechanism in BuildExecutor adjusts this upward when success rates are low or timeout rates are high. Default: 13s (normal), 18s (slow systems).
      Parameters:
      ctx - the router context
      Returns:
      request timeout in ms

    • getFirstHopTimeout

      public static int getFirstHopTimeout(RouterContext ctx)
      How long the OutNetMessage for the first hop gets before TunnelBuildFirstHopFailJob fires. Shorter than request timeout so first-hop failure is detected before the full build timeout.
      Parameters:
      ctx - the router context
      Returns:
      first hop timeout in ms

    • getBuildRequestPeer

      public static Hash getBuildRequestPeer(PooledTunnelCreatorConfig cfg)
      The peer that will receive the tunnel build request (TBM): the gateway (peer 0) for inbound tunnels, or the next hop (peer 1) for outbound tunnels. BuildExecutor's per-peer pacing guard must target the same peer the dispatch code sends the request to, so both use this single derivation.

      Returns null for a config too short to have a hop 1. Exploratory pools build length-1 tunnels whose peer array holds only the gateway, so asking for hop 1 would throw and abandon the build outright — which stops every exploratory pool from populating.

      Parameters:
      cfg - non-null; may be a short config
      Returns:
      the dispatch target peer, or null if the config has no hop 1

    • request

      public static boolean request(RouterContext ctx, PooledTunnelCreatorConfig cfg, BuildExecutor exec, long firstHopTimeout)
      Initiates a tunnel build request.
      Parameters:
      ctx - the router context issuing the build
      cfg - tunnel configuration (must have ReplyMessageId set)
      exec - executor to notify on completion
      firstHopTimeout - adaptive first-hop timeout ms (from BuildExecutor stats)
      Returns:
      true if request was successfully dispatched

    • preConnectFallback

      static boolean preConnectFallback(RouterContext ctx, Hash peer, PooledTunnelCreatorConfig cfg, BuildExecutor exec)
      Approach 2: Fire-and-forget fallback — attempt to establish the transport session and retry the build once. Called from TunnelBuildFirstHopFailJob when the first hop has no established or connecting transport session.

      Calls TunnelPeerSelector.preConnectTo(RouterContext, Hash) to force the session handshake, then re-dispatches the tunnel build message. Returns true if the retry was initiated.

      Parameters:
      ctx - the router context
      peer - the first-hop peer that failed
      cfg - the tunnel configuration
      exec - the build executor to notify on completion
      Returns:
      true if the retry was initiated, false if pre-connect failed and the build should be abandoned