WCF Reliable Messaging

Reliable messaging in WCF implements the WS-ReliableMessaging (WS-RM) protocol, which guarantees that messages sent between a client and service arrive exactly once, in the order they were sent, even when the underlying transport (such as HTTP) provides no such guarantee on its own. Without reliable messaging, a dropped TCP connection or a transient network blip can silently lose a message, and the caller may never know. WS-RM introduces sequence numbers, acknowledgments, and retransmission so that both endpoints can detect gaps and recover without the application code having to implement its own retry logic.

Under the hood, WS-RM establishes a reliable session identified by a sequence, and every message carries a sequence number within that session. The receiving endpoint sends back SequenceAcknowledgement messages listing which numbers it has received, and the sender retransmits anything not yet acknowledged after a timeout. WCF exposes this through binding elements: netTcpBinding and wsHttpBinding both support a <reliableSession> configuration element, and you can also compose a CustomBinding with a ReliableSessionBindingElement layered over a transport binding element such as httpTransport, giving you WS-RM over plain HTTP without WS-HTTP's SOAP security overhead.

The <reliableSession> element takes three key attributes: enabled turns WS-RM on for the binding; ordered controls whether the service must deliver messages to the application in the exact sequence sent (true) or may deliver them as they arrive as long as none are lost (false); and inactivityTimeout defines how long the session can go without traffic before WCF tears it down and faults the channel. A reliable session is distinct from — but often paired with — a security session; enabling reliableSession does not by itself provide authentication or encryption, so you still configure <security> separately on the binding. Because WS-RM sessions carry state (sequence numbers, buffered unacknowledged messages) on both sides, they interact directly with InstanceContextMode.PerSession service instancing, since the reliable session's lifetime is what keeps a per-session service instance alive.

When ordered='true', the receiving WCF runtime buffers out-of-sequence messages in memory until the missing predecessor arrives, then delivers them to the service operation in the correct order; this buffering is bounded by the channel's MaxReceivedMessageSize and related quotas, and a sender that gets far ahead of the receiver's acknowledgments risks the flow-control window forcing it to pause. Because retransmission and buffering consume memory and CPU on both client and service, WS-RM sessions are typically scoped to a bounded, business-critical exchange (like submitting a multi-part purchase order) rather than left open indefinitely; the inactivityTimeout exists precisely to reclaim these resources when a client disappears mid-conversation without a clean close.