[Message Prev][Message
Next][Thread Prev][Thread Next][Message
Index][Thread Index]
RE: Re: Query / Response type messages
- Subject: RE: Re: Query / Response type messages
- From: Edward Pearson
- Date: Thu, 01 Jan 2004 21:21:00 +0000
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0
Transitional//EN">
<TITLE>Message</TITLE>
<DIV><FONT face="Arial" color="#0000ff"
size="2"><SPAN
class="783275620-01012004">That's enourmously helpful, thanks.
I have some revision to do clearly...</SPAN></FONT></DIV>
<DIV><FONT face="Arial" color="#0000ff"
size="2"><SPAN
class="783275620-01012004"></SPAN></FONT> </DIV>
<DIV></DIV>
<DIV class="OutlookMessageHeader" lang="en-us"
dir="ltr" align="left"><FONT
face="Tahoma" size="2">-----Original
Message-----<B>From:</B> Stuart Booth [mailto:lists@xxxxxxx]
<B>Sent:</B> 01 January 2004 20:45<B>To:</B>
xAP_developer@xxxxxxx<B>Subject:</B> Re: [xAP_developer] Re:
Query / Response type messages</FONT></DIV><TT>On Thu, 01
Jan 2004 19:25:19 -0000, "Edward
Pearson"<edward.mailgroup@xxxxxxx> wrote:>3) Oh, what's the
"ACK / sequencing suggestions" stuff? - I may have >missed
something here. Where's it documented (or should I just >search the
archive for ACK?)Here's what I found. There are a few preliminary comments,
of whichthe date/time should help you find them in the web archive
onYahooGroups.Alternatively search for the subject:Subject: [xAP_developer]
Topic 4: Point to point acknowledgeme
nt inxAP messages...from around:Date: Tue, 10 Jun 2003 19:06:40
+0100There's a pile of discussion following on from this.The comments I've
found, including the first on the subject mentionedabove from Kevin are as
follows:66From: "Patrick Lidstone" <patrick@xxxxxxx>Date:
Mon, 19 May 2003 10:55:51 -0000Some feedback I got about xAP from UKHA
2003.- David Buckley pointed out reliability is an issue - xAP messages can
potentially be dropped by the network (although I've never seen it happen
yet, I agree it *could* happen). I think we can solve this to a certain
extent by including an optional sequence number in the header - the
receiver could then potentially detect a missed message, but there are a
number of subtleties involved here, and I don't think we want to add any
more complexity to the protocol - perhaps with a bit of imagination we can
come up with a cheap & easy fix?:9966Subject: [xAP_developer] Topic
4: Point to point acknowledgement inxAP messagesFrom: "Kevin
Hawkins&quo
t; <lists@xxxxxxx>Date: Mon, 19 May 2003 14:37:18 +0100:I had
wondered about the possibility of including a 'ACK=Yes' typeparameter in
targeted messages to effectively confirm delivery of apacket - although
this is a sender to receiver mechanism only (itwouldn't handle the receiver
knowing it had missed something). Usingthis for example a security sensor
could broadcast its statusgenerally (broadcast) and additionally target a
critical receiver withan ACK=Yes mechanism. Towards the end of our
discussion David seemedhappy that if we could include this sort of
mechanism - plus thestandard (universal) parameters for ON/OFF and level -
along withadditionally a defined and standard way of polling the status of
adevice then he would be very happy with xAP - he loves the higherlevel
stuff (text display - DB lookup etc). I think this last bit ofdefining a
status.request along with a status.report type schema thatincludes the
ON/OFF and Level would help everyone here. Maybe there'smore than level but
I think mo
st HA applications (and devices) onlysupport this need.Obviously we need to
address configuration and discovery as well(untargeted message with
Ack=Yes).:9966From: "Patrick Lidstone"
<patrick@xxxxxxx>Date: Mon, 19 May 2003 13:57:28 -0000:Ack=yes is
certainly a simple solution. Even better might be ack=nnn where nnn is a
sequence number/key. Then you know which message is being acked.My only
reservation about an ack=yes scenario is that we are again raising the bar
on the minimum level of functionality required in a device. Perhaps
ack-supporting devices should include an "ack-able" indication in
their heartbeat? That way a sender could discover if a device supports
acking, leaving devices with the option of not supporting it & we
would retain backwards compatibility.9966From: "Patrick Lidstone"
<patrick@xxxxxxx>Date: Tue, 20 May 2003 08:43:14 -0000More thoughts
on this:- 3 scenarios, all ack and sequence related. Negative Ack:Receiver
benefits from detecting
the loss of a message, and can re-request or take action as appropriate,
but doesn't generate any network traffic in the default case where
everything works ok.Positive Ack:Receiver acknowledges receipt of every
message explicitly. Can be useful for flow control (next message isn't sent
until timeout/ack is received). Guarantees that the sender knows an action
was performed.Sequencing:Receiver is able to concatenate sequenced messages
to form a message that is bigger than the underlying transport can handle.
Might be useful one day.Possible mechanism:xap-header{...tm=+
-OR- tm=- -OR- tm is omittedseq=nnn...}where tm is transport mode, and + is
positive ack and - is negative ack and seq is sequence. Sender increments
sequence according to these rules:- If the message is a targeted message,
sequence increments for that specific target- If message is source
addressed, sequence increments for that sourceThe receiver can track
sequence numbers for a source that they are interested in by storing UID
and
sequence number. (UID is proving invaluable...) They would only need to do
that in the negative ack or concatenation scenario.A receiver indicates
supported transport modes by including:xap-hbeat{...tm=+-...}in their
heartbeat.Fully backwards compatible - any of the tm / seq fields may be
omitted, and interoperability should be seamless. Adds a lot of flexibility
(too much?) for very little overhead.9966From: "Kevin Hawkins"
<lists@xxxxxxx>Date: Tue, 10 Jun 2003 19:06:40 +0100OK - a feisty
topic I hope.One of the downsides of having essentially a broadcast
typetransport like xAP (or xPL for that matter) is that
deliveryconfirmation has to be handled as a policy layer rather than
withinthe transport - unless we want to generate huge volumes of
broadcasttraffic which we don't ! This also makes it difficult to support
xAPstate tables within the various external controller applications
thatmaintain such information - or at least to ensure its integrity
orcreate (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
particulartransmission 2)
A mechanism such that a receiver knows it has missed
atransmission 3) A very
basic status request system (as in Topic 1) plusother extra included status
information such that a device can poll areceiver to confirm it's
state 4) Perhaps a way
for a device to bind with another in a way that thedevices are aware if
they miss any messages from each other and cancorrect the
situation. All of these
to work in a targeted message scenario and abroadcast or wildcarded
situation eg target=ukusa.tempsensor.> Plusthe ability to
optionally enable this level of end to endacknowledgement.&nb
sp;
Ideas. A) The inclusion
in a header of ACK=Yes to force all receiverswho have an interest in the
message (satisfies their filters) toacknowledge they have received it. This
will have a varying responsebased on the target addressing used and will
have a beneficial use inconfiguration and discovery of types of
devices. B) The addition
of a sequence number to qualifyingtransmissions to provide indication to a
receiver that a message hasbeen lost - this has additional ramifications
should a messagerecovery/ retry mechanism be
wanted. C) A standard
polling (status) structure such that a devicecan check an action has been
completed. In addition a standard statusmessage be sent (mandatory)
whenever an input on a device
changesstate. D) A single
to multipoint to multipoint (ac
tually several oneto many and many to one) binding system to ensure
integrity of messageexchanges 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 statusresponse to be returned. However
I am not sure that this shouldpreclude 'listeners only' as they have no
real part to play on anetwork and to all intents and purposes don't exist
on it. Others
??? K99-- Stuart Booth
<stuart@xxxxxxx>xAPFramework.net - a xAP software development
framework for .net<A href="http://www.xapautomation.org/";>http://www.xapautomation.org/</A>
<A href="http://www.xapframework.net/";>http://www.xapframework.net/</A></TT><TT>
<HR width="500">
<B>Yahoo! Groups Links</B>
<UL>
<LI>To visit your group on the web, go to:<A href="http://groups.yahoo.com/group/xAP_developer/";>http://groups.yahoo.com/group/xAP_developer/</A>
<LI>To unsubscribe from this group, send an email to:<A
href="mailto:xAP_developer-unsubscribe@xxxxxxx?subject=Unsubscribe";>xAP_developer-unsubscribe@xxxxxxx</A>
<LI>Your use of Yahoo! Groups is subject to the <A href="http://docs.yahoo.com/info/terms/";>Yahoo!
Terms of Service</A>. </LI></UL></TT>
xAP_Development Main Index |
xAP_Development Thread Index |
xAP_Development Home |
Archives Home
|