I have applied all
the agreed changes to the BTP state tables and posted an excel version of these
on the BT TC document list, at
with comments in the
cell to identify which issue it relates to.
There were three
bugfixes that either came out of the testing on this (see below) or had arisen
from implementation but not
been referenced in
issues. I have submitted a new issue - maint-14 - to cover these, and I now
propose resolution of it
in line with these
tables.
Also, in applying
issue ex-10, with the extra values for state on SUPERIOR_STATE, INFERIOR_STATE,
it became apparent that
one more value was
needed. The new values mean that both sides always have some message they can
send, as an acknowledgement
or as a query, even
when the next state-changing action is on their side but hasn't happened yet.
However, when a superior has
determined that a
heuristic (contradiction) has occurred, but hasn't logged it (as it is required
to), there is no message it can usefully
send -
especially because this occurs both when HAZARD has been received, and when the
"wrong" CONFIRMED or CANCELLED has
been received.
Accordingly, I have added a value "contradiction-known" and applied that as part
of the solution to issue ex-10.
Issue ex-10 also
requires an additional state in the inferior. The old state "n1", entered after
CANCEL is received when active has to
be split depending
on whether PREPARE has been received or not. This is needed to cope with the
failure cases where the inferior switches
to a different state
(be clear, this isn't saying that an implementation must be able to switch to
these states, just that it may not
switch to any other,
regardless of failures). An implementation that received PREPARE and then
persisted itself (in active phase,
which BTP allows but
does not require) which then received a CANCEL, and then crashed would, in
that crash, go from back to
having received the
PREPARE only. Previously this was coped with by going to the same
state on CANCEL as if the PREPARE
had not been
received. But this would apparently allow an inferior to enrol,
receive CANCEL,
crash, and then be
in state d1, having received PREPARE which it never had. Previously this didn't
matter; with the addition of
INFERIOR_STATE/prepare-received it can show up as an
illegal message.
As with the BTP 1.0
tables, I have run these through my state table tester and have at least
one scenario showing every valid
transition. I have
also run the tester on the tables for some millions of Monte Carlo runs without
it getting stuck or producing a
wrong
answer. Thus we can be pretty sure that these tables are correct (or
rather, they are self-consistent). I have put html
versions of the
tables, with each cell being a link to a scenario showing it occur on the
Choreology website. These versions
are made accessible
for review and to aid understanding, but are NOT formally submitted to
OASIS.
Peter