Defragmentation channel message retention time
Messages are retained in the defragment channel queue only for a limited time. When one half of the time before the first nondelivery notice is sent has elapsed1 (and a backoff time has elapsed so that the channel is attempting to process relevant message fragments), the various parts of a message will be sent on without being reassembled. This choice of time value (normally) eliminates the possibility of a nondelivery notification being sent about a message in the defragment channel queue.
The notices channel option (and optionally its priority-sensitive variants, *notices) controls the amount of time that can elapse before nondelivery notifications are sent, while the backoff channel option (and optionally its priority-sensitive variants, *backoff) controls when message delivery attempts are made. So between the two of them, they control the amount of time messages are retained before being sent on in pieces, with notices normally being the primary control (controlling how long before the channel "gives us" on attempting to reassemble message fragments), modulated by when the backoff values in fact cause the channel to run and attempt message delivery (hence deliver message fragments that have lingered past half the final notices value and still do not make up a complete message "as is", without reassembly). Set the notices option value to twice the amount of time you wish to retain messages for possible defragmentation (and ensure that the backoff values in effect for the defragment channel are such that a delivery attempt will be made shortly after half the final notices value). For example, normally a notices value of 4 would cause retention of message fragments for two days:
defragment notices 4 defragment-daemon
Or if the more general backoff values do not align well with the defragment channel's notices time scale, then also set some sensible backoff values explicitly on the defragment channel. For instance, setting the final backoff value to p4h means that message (fragments) will get a reassembly-and-possible-delivery attempt every four hours. Hence the following sort of definition:
defragment backoff "p1h" "p2h" "p2h" "p4h" notices 4
will mean that message fragments will get sent on as is (still as fragments, rather than reassembled) after approximately forty-nine hours. (There will be message delivery attempts immediately, then at one hour, three hours, five hours, nine hours, then every four hours thereafter---so the first time past the two day point, the expiration of half of the notices final value, will be at forty-nine hours.)
When the defragment channel cannot reassemble a message, and decides to send onwards a message fragment, it will add a header line
Defragment-failed: official-local-host-name
showing the official_host_name from the L channel.
1Note that the "half" is calculated using integer integral division but not allowed to go below one, so for instance an initial notices value of 5 results in fragments being eligible for delivery after 2 days or hours depending upon return_units, but even an initial notices value of 1 still means fragments aren't eligible for delivery until after 1 day or hour.
See also:
