The WS-RM Sequence Lifetime in Indigo
There are two mechanisms in the WS-ReliableMessaging protocol that affect the lifetime of a sequence - the Expires element located in CreateSequence and CreateSequenceResponse messages and the InactivityTimeout policy assertion located in a service's WSDL. In Beta 1, Indigo simply ignores the first one and has a mechanism in place that tries to prevent the timeout defined by the second one from ever being actually reached. Indigo's architects and developers had good reasons to do things this way. It all makes sense when you think about the two reliable communication models that are currently available in the product - a queued one and a direct one. The queued communication model is meant mainly for long-running, disconnected, durable applications; on the other hand, the direct communication model is "alive" - both parties need to be online at the same time and their state is stored in-memory as they exchange their messages. This post addresses the second model.
Let's cover the optional Expires element first. Indigo clients never generate it and Indigo services echo back whatever the client asked for as that's what's required by the WS-RM specification. That's also all an Indigo service will do - if the client was serious enough about the Expires duration to put it in the CreateSequence, it will be up to the client to enforce it, as well. There is nothing in the spec that says the RM Receiver is obligated to terminate the sequence when the duration expires.
The InactivityTimeout is more interesting. If there is no traffic on an RM sequence, and that includes application as well as protocol messages, for the duration of the inactivity timeout, the sequence can be considered terminated. An Indigo service resets its inactivity timer every time it receives a message on a given sequence. When the timer goes off, however, it will send a SequenceTerminated fault to the client and erase all state it had associated with that sequence. An Indigo client is different. An Indigo client wants to keep the "direct" sequence alive for the user and prevent the service from terminating it due to inactivity. To do this, it sends "keep-alive" messages. Keep-alives are simple AckRequested messages that probe the sequence to a) make sure it's not dead and b) to inform the service the client is still active. If an Indigo client doesn't receive acknowledgements for its keep-alives for the duration of the inactivity timeout, it will also terminate the sequence and send a SequenceTerminated fault to the service.
Let's get into the nitty-gritty details about when we actually send these keep-alive messages. We'll send the first one when the client hasn't heard back from the service for half of the inactivity timeout. At that point, we split the second half of the inactivity timeout into MaxRetryCount segments. If the server continues to respond with silence, we'll send one AckRequested at the end of every one of the calculated segments. The client will give up after MaxRetryCount AckRequesteds.
I hope this gave you some more insight into how Indigo deals with the lifetime of a sequence and that this will all come in handy when debugging isses that arise as a result of it - whether in Indigo-to-Indigo or cross-vendor configurations.
