ack-ing (was Re: Feedback from UHKA 2003)

[Patrick Lidstone]

More thoughts on this:

- 3 scenarios, all ack and sequence related.

Negative Ack:
Receiver benefits from detecting the loss of a message, and can re-
request or take action as appropriate, but doesn't generate any
network traffic in the default case where everything works ok.

Positive Ack:
Receiver acknowledges receipt of every message explicitly. Can be
useful for flow control (next message isn't sent until timeout/ack is
received). Guarantees that the sender knows an action was performed.

Sequencing:
Receiver is able to concatenate sequenced messages to form a message
that is bigger than the underlying transport can handle. Might be
useful one day.


Possible mechanism:

xap-header
{
...
tm=+ -OR- tm=- -OR- tm is omitted
seq=nnn
...
}

where tm is transport mode, and + is positive ack and - is negative
ack and seq is sequence.

Sender increments sequence according to these rules:
- If the message is a targeted message, sequence increments for that
specific target
- If message is source addressed, sequence increments for that source

The receiver can track sequence numbers for a source that they are
interested in by storing UID and sequence number. (UID is proving
invaluable...) They would only need to do that in the negative ack or
concatenation scenario.

A receiver indicates supported transport modes by including:

xap-hbeat
{
...
tm=+-
...
}

in their heartbeat.

Fully backwards compatible - any of the tm / seq fields may be
omitted, and interoperability should be seamless. Adds a lot of
flexibility (too much?) for very little overhead.

Patrick