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 Summary

Fields

Modifier and Type	Field	Description
static String	BUNDLE_REPLY_LEASESET	NOTE: Changed as of 0.9.2.
static String	OVERALL_TIMEOUT_MS_PARAM	final timeout (in milliseconds) that the outbound message will fail in.

Constructor Summary

Constructors

Constructor	Description
OutboundClientMessageOneShotJob(RouterContext ctx, OutboundCache cache, ClientMessage msg)	Send it.

Method Summary

Modifier and Type	Method	Description
String	getName()	Descriptive name of the task
static void	init(RouterContext ctx)	call once only
void	runJob()	Actually perform the task.

Methods inherited from class net.i2p.router.JobImpl

dropped, getAddedBy, getContext, getJobId, getMadeReadyOn, getTiming, madeReady, requeue, toString

Methods inherited from class java.lang.Object

clone, equals, finalize, getClass, hashCode, notify, notifyAll, wait, wait, wait

Field Detail

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 Detail

OutboundClientMessageOneShotJob

public OutboundClientMessageOneShotJob(RouterContext ctx,
                                       OutboundCache cache,
                                       ClientMessage msg)

Send it.

Parameters:

msg - may have a null payload for ratchet-layer acks

Method Detail

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.