The UK Home Automation Archive

Archive Home
Group Home
Search Archive


Advanced Search

The UKHA-ARCHIVE IS CEASING OPERATIONS 31 DEC 2024


[Message Prev][Message Next][Thread Prev][Thread Next][Message Index][Thread Index]

Topic 4: Point to point acknowledgement in xAP messages


  • Subject: Topic 4: Point to point acknowledgement in xAP messages
  • From: Kevin Hawkins
  • Date: Tue, 10 Jun 2003 19:06:00 +0000

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







xAP_Development Main Index | xAP_Development Thread Index | xAP_Development Home | Archives Home

Comments to the Webmaster are always welcomed, please use this contact form . Note that as this site is a mailing list archive, the Webmaster has no control over the contents of the messages. Comments about message content should be directed to the relevant mailing list.