Next][Thread Prev][Thread Next][Message
ack-ing (was Re: Feedback from UHKA 2003)
- Subject: ack-ing (was Re: Feedback from UHKA 2003)
- From: Patrick Lidstone
- Date: Tue, 20 May 2003 09:43:00 +0000
More thoughts on this:
- 3 scenarios, all ack and sequence related.
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.
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.
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.
tm=+ -OR- tm=- -OR- tm is omitted
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
- 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
A receiver indicates supported transport modes by including:
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.
xAP_Development Main Index |
xAP_Development Thread Index |
xAP_Development Home |