RE: [bt-spec] BTP Issue 81 : Resending ENROL

[Peter Furniss <peter.furniss@choreology.com>]

The inferior-identiifer on all the ENROLs from (on behalf of) the same Inferior will be the same, so the Superior can spot a resend.

 

There are some state table changes:

 

The arrival of a resent ENROL means the creation of a new state for the Superior, B2, from which a second ENROLLED can be sent, which takes the Superior back to B1 (its normal active state) - the repeat ENROLLED is needed as the Inferiors repetition means it probably didn't get the first ENROLLED. As is the general pattern, if another ENROL turns up before the first has been replied to (or a third before the second etc), only one ENROLLED is sent back.

 

Allowing a second ENROL and thus a second ENROLLED means that these can turn up in various states where they are boring (e.g.. the first one didn't get lost, just delayed, so the receiver has already cancelled or some such).

 

The state tables have assumed both ENROL/rsp-req and ENROL/no-rsp-req can be repeated. They in fact allow ENROL/no-rsp-req to be sent after ENROL/rsp-req has been sent and ENROLLED received, but this is because there is only one inferior active state - b1.  Preventing the no-rsp-req after receiving ENROLLED would require the creation of another state, distinguishing what the completed enrolled sequence did. This does not seem worth while.

 

New state tables with these changes are included in draft 0.9.1.3, and a new set of information hyperlinked example sequence diagrams are on http://www.choreolgoy.com/~btp

 

In the state tables in 0.9.1.3, the changes marked in green (for the ENROL/rsp-req changes) and cyan (for the ENROL/no-rsp-req changes)

 

Proposed solution

 

Allow repeat ENROL/rsp-req to be sent from inferior after it has sent it, but not received an ENROLLED (i.e. in state a1)

Allow repeat ENROL/no-rsp-req to be sent from inferior after it has it, (i.e. in state b1)

 

Add a superior state B2, entered after receiving a second ENROL/rsp/req. Sending ENROLLED returns to B1, cannot send SUPERIOR_STATE (use ENROLLED instead) otherwise identical to B1.

 

Allow inferior to accept (and ignore) ENROLLED in states where this is now possible.

 

 

Peter

 

-----Original Message-----
From: Mark Little [mailto:mcl@arjuna.com]
Sent: 30 November 2001 19:20
To: bt-spec@lists.oasis-open.org
Subject: Re: [bt-spec] BTP Issue 81 : Resending ENROL

 

Submitter: Choreology
Category: minor technical
Description:
ENROL currently cannot be resent (with the same identifiers). This seems to be wrong - it can be unambiguously identified as a repeat, and not allowing it makes enrollment more fragile than other actions.

---

I agree - as long as it can be guaranteed that the receiver can identify this as a resend. In which case ENROLLED should be re-sendable too.

 

Mark.

 

----------------------------------------------
Dr. Mark Little, Distinguished Engineer,
Transactions Architect, HP Arjuna Labs
Email: mark@arjuna.com | mark_little@hp.com
Phone: +44 191 2064538
Fax  : +44 191 2064203