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]

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


  • Subject: RE: Topic 4: Point to point acknowledgement in xAP messages
  • From: Ian B
  • Date: Tue, 10 Jun 2003 22:14:00 +0000

Just a couple of 'how I am doing it' views.

Acknowledgement - I am sending a heartbeat in return with a body giving
'status=0  1  etc. Zero means no error and the other values indicate where
the error happened. If it gets this far the message has been identified as
for my unit specifically.

Input change - I have an inputs schema and part of this is an event
notification. This gives the new logical state of the input in question
e.g.
'input1=high'. I have used logical states not on and off as this assumes
something that shouldn't be assumed.

More later if I get time cos I am playing graphic screens at the moment.

Ian

>-----Original Message-----
>From: Kevin Hawkins [mailto:<a
href="/group/xAP_developer/post?postID=AbQNslFMnFnedSvy3Kg-oPfncv6sq3dmJ1X6Nxn7JY3ystXZwYu7GRNmKmUOMOJd2_sJCojgU-IKXJdHZqHF">lists@u...</a>]
>Sent: 10 June 2003 19:07
>To: <a
href="/group/xAP_developer/post?postID=QD_8LIG3-_Oqj4X0ryauDZmnDvXVgeT7OTcApbpZxqm0-k4wKI3YyPiFq_HTD_clL8opWv4Ow8XBb3R3lPD14Zgnr1I">xAP_developer@xxxxxxx</a>
>Subject: [xAP_developer] Topic 4: Point to point acknowledgement in xAP
>messages
>
>
>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
>
>
>
>
>To unsubscribe from this group, send an email to:
><a
href="/group/xAP_developer/post?postID=MqdeLOc7k0BcAiwq9eLOUFKc8NTBF8RPDBmG7f1hgoX-NlAXsjwGELg9VZ5TvIPiDcXQp6o8WRgHOXdO0EI7kQHXNj_Z5vSgni_ONGbVXXMJbs0">xAP_developer-unsubscribe@xxxxxxx</a>
>
>
>
>Your use of Yahoo! Groups is subject to <a href="http://docs.yahoo.com/info/terms/";>http://docs.yahoo.com/info/terms/</a>
>
>
>







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.