Retries, expirations, and returned data

The shipping server makes one attempt to transmit a packet to another host. If the packet cannot be transmitted (for example, because the receiving host is unavailable), the shipping server generates an error message and log file entry and exits.
You can set up a retry scheme to control its frequency:
Attempts to transmit an undelivered packet can continue indefinitely, through repeated invocations of the shipping_server command. However, you usually want to fix problems with failed transmissions instead of letting the attempts continue. Accordingly, each shipping order can include an expiration date-time, specified with one of the following:

By default, shipping orders expire 14 days after they are created.

When the shipping server encounters a shipping order that has expired, it does not attempt to transmit the corresponding packet to its destination. Instead, it does the following:

The return trip may involve multiple hops. During such a trip, a packet is placed in the return bay of each intermediate host. Each hop is handled by shipping_server –poll, which processes a host’s return bay in addition to its storage bays. The expiration time for a packet’s return trip is 14 days; a packet that cannot be returned in that interval is deleted.


Feedback