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

[Patrick Lidstone]

I've been thinking more about this, and I don't think that we can use
positive ack for anything other than one-to-one communications. That
would be the situation where we used a non-wildcarded target address.
Is that special case worth specifying a +ve ack for alone?

Using a -ve ack works much, much better in the many-to-many
environment, because it prevents network meltdown.

> Which sort of leads on to a retry type problem - if you did ask say
all you
> relays to pulse on for 1 sec but one device missed it - we may need
a way of
> resending it such that devices that already had done this didn't do
it
> again. A sort of retry/transaction identifier.

Receivers who heard the retransmitted message would simply discard it
because the sequence number would be less than the expected next
match. Does this address your scenario or have I misunderstood?


> I tend to agree this may be best in the HB - maybe as a body part
even ??

ITYM as part of the conventional message header? I think that would
work too (possibly better - the inclusion of a sequence number is an
implicit indication that acking is supported, would we ever need to
know whether acking was supported before a message was sent?).

> In
> one of the other threads I was proposing that all devices (capable
of
> transmitting & receiving xAP messages MUST implement a minimal
status
> response) - ie making this mandatory when they are specifically
targeted.

OK, perhaps I missed that. I would be reluctant to insist on a change
to the protocol which insisted that every device *had* to be sender
and receiver. Today we can stick a dumb device on the network which
just "chatters" xAP, without the need for any recieving
capability at
all (e.g. a simple telemetry device) - it seems a shame to throw that
away.

> Some network actions (housekeeping / config) for example might say
> put a device into a state where it will only respond to level 1
data -
> obtaining a devices total attention and avoiding a device getting
> sidetracked by other broadcast data.

This has a lot of potential. It could be the missing link in the
config mechanism perhaps - that solves the Dr.John scenario of many
devices that are installed at the same time.

Patrick