Re: Topic 4: Point to point acknowledgement in xAP messages

[Patrick Lidstone]

> tm is a little cryptic in a message header where readable is
the
> norm, I prefer ACK (or Acknowledge or Reply)
>
> I like the ability to both positive acknowledge and negative
> acknowledge. As I see it a device should negative acknowledge when
it
> determines it has missed a message that was meant for itself -
either
> because it sees a targeted message at itself where a previously
sequenced
> message is missing or it manages to get the addressing info but the
payload
> is corrupted (unlikely). Are there other situations - eg it doesn't
see a
> message it expected perhaps.

This could be dodgy ground. I would argue that a checksum failure is
grounds for a requesting a retry, but that an otherwise malformed
message (unexpected content etc) is not - since this can't be
corrected by a simple retransmission, so it should simply be
discarded by the recipient.

Somehow we need to guard against a flood of retry requests from
multiple recipients...

> Re the sequencing - that obviously works but requires a
device that
> wants to use targeting to maintain a separate sequence number for
each
> device - adding to overhead - useful though I think. What happens
though in
> a target=UKUSA.thermostat.> scenario - I assume that targets will
have to be
> single matches to support specific sequencing.

Yes, I think this needs more thought. A unique sequence number count
is probably maintained for each set of unique (UID, target string)?
It is only a couple of bytes, so it's not too burdensome.

> At the point acknowledges are requested in a one to many
scenario
> then the various receivers will have to start to pay attention to
the
> sequence numbers - we may need a 'pay attention from now on' type
message to
> enable acknowledges ( or neg acknowledges) in a one to many
scenario.

I don't think we want (or need) to be able to turn acking on/off. I
can't think of a scenario in which this would be useful, and I can
see all sorts of potential difficulties arising if either the
"on"
or "off" message itself gets lost.

>Do we
> need to have an ability to turn negative acknowledges off on
specific
> devices remotely. (Negative acks could appear for all messages, non
> targeted)
>
> I think it would be nice to tidy up the retry mechanism in a
> standard way - rather than leave it to individual implementation in
the
> application layer. That way all our devices will interoperate
nicely - we
> also probably need to discuss a max number of retries scenario when
a device
> attempts communication but is unable to succeed for whatever reason
and
> gives up - but this may be supportable at an application layer.

Max retry count is a good idea. This could also be time based.

> A device can as you say in it's heartbeat indicate whether it
can
> support positive/negative acks and sequencing - this is the logical
place
> for it - but- thinking ahead are there a load of such capabilities
that we
> may need to be able to report - for example support for targeting -
support
> for wildcarding - depth of addressing supported etc - should all
these sit
> in a xAP.capabilities 'status' type response - that way they don't
clutter
> the network up by being (redundantly) included in every heartbeat ?

I think including them in the HB is quite elegant, it doesn't raise
the bar too high. There's no reason why they shouldn't be duplicated
in a status request/response, but I can't see smaller devices
bothering to implement the ability to generate a status request,
whereas parsing the HB is trivial.

> Do we need any form of priority mechanism in xAP at the
protocol
> layer ??

This is an interesting idea! But what does priority actually mean?
There shouldn't typically be queues of messages sitting around, so
there isn't any means for a message to "overtake" another.
Similarly,
the actual processing of a message shouldn't take very long, so
interrupting the current messages doesn't seem to make a lot of sense?

Patrick