Sun Java System Messaging Server 6.3 Administration Guide

12.8.2.1 Defragmentation Channel

Messages are routed to the defragment channel if the defragment keyword is on a destination channel. That is, when the defragment keyword is present on a destination channel to which the MTA would normally enqueue a message, the MTA "looks inside" (MIME parses) the message structure and if the MTA sees that the structure is a MIME message fragment, then the MTA automatically routes the message to the defragment channel rather than straight to the (normal) destination channel.

The defragment database contains information about message fragments coming into the MTA including information indicating the host on which each message fragment is received. Once an initial fragment has been received and noted in the defragment database, any other parts of the message that are received on any other systems using the same defragment database will get routed to the host that received the very first part. For instance:

  1. message/partial; id=123; part=x arrives on host 1 and is routed to the defragment channel on host 1 due to the defragment keyword being present on what would otherwise be the destination/outbound channel.

  2. Defragment channel on host 1 checks the defragment database for whether any other parts of this message have yet arrived. If none have, the defragment channel (on host 1) enters this part into the defragment database marking the part as being on host 1.

  3. message/partial; id=123; part=y arrives on host 2 and is routed to the defragment channel on host 2 due to the defragment keyword being present on what would otherwise be the destination/outbound channel.

  4. Defragment channel on host 2 checks the defragment database, sees that part x of this message is already present and stored on host 1. The defragment channel redirects the message fragment to host 1 (source routes the address with @host1).

  5. message/partial' id=123; part=y arrives on host 1, is routed to the defragment channel, the defragment channel runs and enters it into the database, and so on.

All remaining parts of a fragmented message are redirected to the host that received the first (first receiving, not necessarily part=1) part of the message. They are reassembled by that host's defragment channel and eventually a reassembled, defragmented message (or if the defragmentation efforts times out, due to exceeding notices, the individual fragments are sent on as-is) is sent onwards to the real destination channel. You get some load-balancing of the defragmentation of messages depending upon which host happens to receive the "first" part of each message.