Re: Re: Query / Response type messages

[Stuart Booth]

On Thu, 01 Jan 2004 19:25:19 -0000, "Edward Pearson"
<<a
href="/group/xAP_developer/post?postID=73o52FOEkhfHnEZDDGzbLJ1T0Ke3rYe6vQZjvXDNC1_ojspLYyF2TmUYQNwnlm5FS3ks_iKTaI7haNKSongYXvTZX7UwLt2JIo_F">edward.mailgroup@b...</a>>
wrote:

>3) Oh, what's the "ACK / sequencing suggestions" stuff? - I
may have
>missed something here. Where's it documented (or should I just
>search the archive for ACK?)

Here's what I found. There are a few preliminary comments, of which
the date/time should help you find them in the web archive on
YahooGroups.

Alternatively search for the subject:

Subject: [xAP_developer] Topic 4: Point to point acknowledgement in
xAP messages

...from around:

Date: Tue, 10 Jun 2003 19:06:40 +0100

There's a pile of discussion following on from this.

The comments I've found, including the first on the subject mentioned
above from Kevin are as follows:

66
From: "Patrick Lidstone" <<a
href="/group/xAP_developer/post?postID=45N2HIiQq-_co1ZD3YnGgbaoj5VaoxA0I0ejZCEG0M3KZI46-wyo8WWhnYlzZJVJZR4dDcJzzT7mgrzSOv-4">patrick@l...</a>>
Date: Mon, 19 May 2003 10:55:51 -0000

Some feedback I got about xAP from UKHA 2003.

- David Buckley pointed out reliability is an issue - xAP messages
can potentially be dropped by the network (although I've never seen
it happen yet, I agree it *could* happen). I think we can solve this
to a certain extent by including an optional sequence number in the
header - the receiver could then potentially detect a missed message,
but there are a number of subtleties involved here, and I don't think
we want to add any more complexity to the protocol - perhaps with a
bit of imagination we can come up with a cheap &amp; easy fix?
:
99


66
Subject: [xAP_developer] Topic 4: Point to point acknowledgement in
xAP messages
From: "Kevin Hawkins" <<a
href="/group/xAP_developer/post?postID=zyKPaxSIlhWdl0y8VJgVu-1j0C4WkZPmezSUIky3ROnfAgBB0sS8GrtTdJdfQKTA4jBsFrXkg-Vmyv7x9S-38Q">lists@u...</a>>
Date: Mon, 19 May 2003 14:37:18 +0100
:
I had wondered about the possibility of including a 'ACK=Yes' type
parameter in targeted messages to effectively confirm delivery of a
packet - although this is a sender to receiver mechanism only (it
wouldn't handle the receiver knowing it had missed something). Using
this for example a security sensor could broadcast its status
generally (broadcast) and additionally target a critical receiver with
an ACK=Yes mechanism. Towards the end of our discussion David seemed
happy that if we could include this sort of mechanism - plus the
standard (universal) parameters for ON/OFF and level - along with
additionally a defined and standard way of polling the status of a
device then he would be very happy with xAP - he loves the higher
level stuff (text display - DB lookup etc). I think this last bit of
defining a status.request along with a status.report type schema that
includes the ON/OFF and Level would help everyone here. Maybe there's
more than level but I think most HA applications (and devices) only
support this need.

Obviously we need to address configuration and discovery as well
(untargeted message with Ack=Yes).
:
99

66
From: "Patrick Lidstone" <<a
href="/group/xAP_developer/post?postID=45N2HIiQq-_co1ZD3YnGgbaoj5VaoxA0I0ejZCEG0M3KZI46-wyo8WWhnYlzZJVJZR4dDcJzzT7mgrzSOv-4">patrick@l...</a>>
Date: Mon, 19 May 2003 13:57:28 -0000
:
Ack=yes is certainly a simple solution. Even better might be ack=nnn
where nnn is a sequence number/key. Then you know which message is
being acked.

My only reservation about an ack=yes scenario is that we are again
raising the bar on the minimum level of functionality required in a
device. Perhaps ack-supporting devices should include an
"ack-able"
indication in their heartbeat? That way a sender could discover if a
device supports acking, leaving devices with the option of not
supporting it &amp; we would retain backwards compatibility.
99

66
From: "Patrick Lidstone" <<a
href="/group/xAP_developer/post?postID=45N2HIiQq-_co1ZD3YnGgbaoj5VaoxA0I0ejZCEG0M3KZI46-wyo8WWhnYlzZJVJZR4dDcJzzT7mgrzSOv-4">patrick@l...</a>>
Date: Tue, 20 May 2003 08:43:14 -0000

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.
99

66
From: "Kevin Hawkins" <<a
href="/group/xAP_developer/post?postID=zyKPaxSIlhWdl0y8VJgVu-1j0C4WkZPmezSUIky3ROnfAgBB0sS8GrtTdJdfQKTA4jBsFrXkg-Vmyv7x9S-38Q">lists@u...</a>>
Date: Tue, 10 Jun 2003 19:06:40 +0100

OK - a feisty topic I hope.

One of the downsides of having essentially a broadcast type
transport like xAP (or xPL for that matter) is that delivery
confirmation has to be handled as a policy layer rather than within
the transport - unless we want to generate huge volumes of broadcast
traffic which we don't ! This also makes it difficult to support xAP
state tables within the various external controller applications that
maintain such information - or at least to ensure its integrity or
create (validate) a state table on demand.

So as I see it we need to consider the following

1) Confirmation that a receiver has received a particular
transmission
2) A mechanism such that a receiver knows it has missed a
transmission
3) A very basic status request system (as in Topic 1) plus
other extra included status information such that a device can poll a
receiver to confirm it's state
4) Perhaps a way for a device to bind with another in a way that the
devices are aware if they miss any messages from each other and can
correct the situation.

All of these to work in a targeted message scenario and a
broadcast or wildcarded situation eg target=ukusa.tempsensor.> Plus
the ability to optionally enable this level of end to end
acknowledgement.

Ideas.

A) The inclusion in a header of ACK=Yes to force all receivers
who have an interest in the message (satisfies their filters) to
acknowledge they have received it. This will have a varying response
based on the target addressing used and will have a beneficial use in
configuration and discovery of types of devices.

B) The addition of a sequence number to qualifying
transmissions to provide indication to a receiver that a message has
been lost - this has additional ramifications should a message
recovery/ retry mechanism be wanted.

C) A standard polling (status) structure such that a device
can check an action has been completed. In addition a standard status
message be sent (mandatory) whenever an input on a device changes
state.

D) A single to multipoint to multipoint (actually several one
to many and many to one) binding system to ensure integrity of message
exchanges between critical devices

E) MANDATORY support for Target= mysourceaddress and Target
=*.*.> (or Target=> within every xAP compatible receiving device
(currently optional)- plus MANDATORY support for a basic level status
response to be returned. However I am not sure that this should
preclude 'listeners only' as they have no real part to play on a
network and to all intents and purposes don't exist on it.

Others ???

K
99
--
Stuart Booth <<a
href="/group/xAP_developer/post?postID=jdCky1NakGD1qDn3xF5Q2TvlCf7tmPY2Q8bstNB0yNtJtKkXTUuYHsM3Ww1CLAMqyfyHYw1XDXSWoDFtUkI">stuart@x...</a>>
xAPFramework.net - a xAP software development framework for .net

<a href="http://www.xapautomation.org/";>http://www.xapautomation.org/</a>
<a href="http://www.xapframework.net/";>http://www.xapframework.net/</a>