Class OutboundClientMessageOneShotJob
- All Implemented Interfaces:
Job
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
-
Constructor Summary
ConstructorDescriptionOutboundClientMessageOneShotJob
(RouterContext ctx, OutboundCache cache, ClientMessage msg) Send it. -
Method Summary
Modifier and TypeMethodDescriptiongetName()
Descriptive name of the taskstatic void
init
(RouterContext ctx) call once onlyvoid
runJob()
Actually perform the task.Methods inherited from class net.i2p.router.JobImpl
dropped, getAddedBy, getContext, getJobId, getMadeReadyOn, getTiming, madeReady, madeReady, requeue, toString
-
Field Details
-
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:
-
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:
-
-
Constructor Details
-
OutboundClientMessageOneShotJob
Send it.- Parameters:
msg
- may have a null payload for ratchet-layer acks
-
-
Method Details