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