Package net.i2p.router.message

Class OutboundClientMessageOneShotJob

java.lang.Object
net.i2p.router.JobImpl
net.i2p.router.message.OutboundClientMessageOneShotJob
All Implemented Interfaces:
Job
public class OutboundClientMessageOneShotJob
extends JobImpl
Send a client message out an outbound tunnel and into an inbound tunnel on the target leaseSet. This also (sometimes) bundles the sender's leaseSet and a DeliveryStatusMessage (for ACKing any sessionTags used in the garlic).

This class is where we make several important decisions about what to send and what path to send it over. These decisions will dramatically affect:

  • Local performance and outbound bandwidth usage
  • Streaming performance and reliability
  • Overall network performace and connection congestion

For the outbound message, we build and encrypt a garlic message, after making the following decisions:

  • Whether to bundle our leaseset
  • Whether to bundle session tags, and if so, how many
  • Whether to bundle an encrypted DeliveryStatusMessage to be returned to us as an acknowledgement

Also, we make the following path selection decisions:

  • What outbound client tunnel of ours to use send the message out
  • What inbound client tunnel of his (i.e. lease, chosen from his leaseset) to use to send the message in
  • If a DeliveryStatusMessage is bundled, What inbound client tunnel of ours do we specify to receive it

Note that the 4th tunnel in the DeliveryStatusMessage's round trip (his outbound tunnel) is not selected by us, it is chosen by the recipient.

If a DeliveryStatusMessage is sent, a listener is registered to wait for its reply. When a reply is received, or the timeout is reached, this is noted and will influence subsequent bundling and path selection decisions.

Path selection decisions are cached and reused if still valid and if previous deliveries were apparently successful. This significantly reduces out-of-order delivery and network connection congestion. Caching is based on the local/remote destination pair.

Bundling decisions, and both messaging and reply expiration times, are generally set here but may be overridden by the client on a per-message basis. Within clients, there may be overall settings or per-message settings. The streaming lib also overrides defaults for some messages. A datagram-based DHT application may need significantly different settings than a streaming application. For an application such as a bittorrent client that sends both types of traffic on the same tunnels, it is important to tune the settings for efficiency and performance. The per-session and per-message overrides are set via I2CP.

  • Field Details

    • OVERALL_TIMEOUT_MS_PARAM

      public static final String OVERALL_TIMEOUT_MS_PARAM
      final timeout (in milliseconds) that the outbound message will fail in. This can be overridden in the router.config or the client's session config (the client's session config takes precedence)
      See Also:
      Constant Field Values

    • BUNDLE_REPLY_LEASESET

      public static final String BUNDLE_REPLY_LEASESET
      NOTE: Changed as of 0.9.2. Defaults to true. If the client's config specifies shouldBundleReplyInfo=true, messages sent from that client to any peers will periodically include the sending destination's current LeaseSet (allowing the recipient to reply without having to do a full netDb lookup). This should improve performance during the initial negotiations. For clients that do not publish their LeaseSet, this option must be true for any reply to be possible. Setting to "false" may save significant outbound bandwidth, especially if the client is configured with a large number of inbound tunnels (Leases). If replies are still required, this may shift the bandwidth burden to the far-end client and the floodfill. There are several cases where "false" is may be appropriate:
      • Unidirectional communication, no reply required
      • LeaseSet is published and higher reply latency is acceptable
      • LeaseSet is published, client is a "server", all connections are inbound so the connecting far-end destination obviously has the leaseset already. Connections are either short, or it is acceptable for latency on a long-lived connection to temporarily increase while the other end re-fetches the LeaseSet after expiration. HTTP servers may fit these requirements.
      See Also:
      Constant Field Values

  • Constructor Details

  • Method Details

    • init

      public static void init​(RouterContext ctx)
      call once only

    • getName

      public String getName()
      Description copied from interface: Job
      Descriptive name of the task

    • runJob

      public void runJob()
      Description copied from interface: Job
      Actually perform the task. This call blocks until the Job is complete.