Reliable Sequence Creation in WS-RM
The WS-ReliableMessaging spec does not address the issue of lost CreateSequence requests and lost CreateSequenceResponse replies. Despite that, it is clear that every implementation of WS-RM will want to do this and Indigo is one of them. Knowing how Indigo handles this may be useful if your application uses WS-RM, and especially useful if you are interoperating with another WS-RM stack.
In the case of both simplex and duplex RM, an Indigo client will send as many CreateSequence requests as necessary until it receives a matching CreateSequenceResponse reply. Indigo doesn't consider retrying a CreateSequence as a retransmission of the first attempt and thus every CreateSequence retry carries a unique MessageID. Indigo will do this up to MaxRetryCount at which point it will give up and the Open method will throw. Note that a received CreateSequenceResponse that is related to an old CreateSequence attempt (i.e. a new CreateSequence was sent after it) will not be accepted.
In the case of simplex RM, the server has an easy job - it will generate a new sequence identifier for every CreateSequence that comes in. Since each CreateSequence carries a unique MessageID, there can be no disagreement over whether the same sequence identifier should be sent for what may have been a CreateSequence retry. An Indigo client will consume and use the first CreateSequenceResponse it can and ignore all subsequent ones.
The situation is a bit more complex in the case of duplex RM where two sequence identifiers are involved - one being sent by the client to the service (the offered sequence identifier for messages flowing from the RM service to the RM client) and one being sent by the service to the client (the sequence identifier for messages flowing from the RM client to the RM service). An Indigo client doesn't have a lot to worry about - it will send CreateSequence requests with unique MessageIDs and keep the offered sequence identifier the same (you'll see later why there's no need to use a new one). The question is, what does the server do?
It turns out the server can no longer return a new sequence identifier for every CreateSequence. It must check the offered sequence identifier and, if it has seen it before, also return the same sequence identifier it has returned before. This has to happen so that there is no ambiguity over where messages should be sent later on. The server cannot have two different incoming sequence identifiers associated with the same outgoing sequence identifier.
Imagine the case a CreateSequence (with Offer ID X) is duplicated on the network (by the way, this is why it didn't matter if the client reused the same ID: the server may end up getting CreateSequence requests with the same offer ID anyways). If the server returned different sequence identifiers (A and B) it would have two association records in its memory (X-A and X-B). This isn't a state a server wants to be in because once X-A is established, establishing X-B would be an error. Even worse, if the server only kept the latest association on record (so the association for sequence X would change from A to B after the server received the second CS), the client sending a message with ID A would now be locked out.
This hopefully gives you a better idea about why Indigo's reliable channels take care of session initiation the way they do.
