Creating a CM Transport

To send or receive messages using certified delivery features, a program must first create a CM transport (also called a delivery-tracking transport). Each CM transport employs an ordinary transport for network communications. The CM transport adds information so that it can participate in certified delivery protocols; the additional information includes a name and a ledger.

Table 26 CM Transport Creation Calls
C	tibrvcmTransport_Create()
C++	TibrvCmTransport::create()
Java	TibrvCmTransport()
.NET	CMTransport

CM Correspondent Name

Each CM transport has a name—which may be reusable, or non-reusable. The name identifies the CM transport to other CM transports, and is part of the CM label that identifies outbound messages from the CM transport.

A name is reusable when a program supplies it explicitly to the CM transport creation call. When a CM transport with a reusable name also has a file-based ledger, it operates as an instance of a persistent correspondent—which allows continuity of certified delivery beyond transport invalidation and program restarts (for more information, see Persistent Correspondents).

Two CM transports must not bind the same reusable name—that is, at any moment in time, each reusable name must be unique throughout the network. CM transports may reuse a name sequentially, but not simultaneously. Violating this rule can significantly obstruct certified delivery.

Programs may omit the name from the CM transport creation call—in which case the call generates a unique, non-reusable name for the CM transport. No other CM transport on any computer can ever have the same name. As a result, a CM transport with a non-reusable name operates as a transient correspondent—no subsequent CM transport can continue the certified delivery behavior of a transient CM transport.

Correspondent names have the same syntax as Rendezvous subject names. For more information about the syntax of reusable names, and good practice when selecting a reusable name, see Reusable Names. For further details about the syntax of Rendezvous subject names, see Subject Names.

Ledger

Each CM transport keeps a ledger, in which it records information about every unresolved outbound certified message, every subject for which this CM transport receives (inbound) certified messages, and other cooperating CM transports.

Programs may store the ledger in a ledger file, or in process-based storage within the running program. (Even when a CM transport uses a ledger file, it may sometimes replicate parts of the ledger in process-based storage for efficiency; however, programmers cannot rely on this replication.)

Ledger files must be unique. That is, two CM transports must not use the same ledger file (concurrently).

A CM transport with a file-based ledger and a reusable name qualifies as a persistent correspondent, with certified delivery behavior that can extend beyond CM transport destruction.