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

[Kevin Hawkins]

Just thinking about points 4) and D) below and it struck me that tcp
would provide the solution - should we allow a tcp connection to be created
between two partner xAP's on a network - if we did then we don't have to
consider any layers above (or policy) all we would have to do is MANDATE in
the spec that a corresponding udp packet be sent as well (for the broadcast
preservation). This would increase network traffic though - but maybe not
as
much as even a higher level protocol or policy would. This would only be
used for critical partners - perhaps a boiler and thermostats or (heaven
forbid) a security system and sensors.

K

> -----Original Message-----
> From: Kevin Hawkins [mailto:<a
href="/group/xAP_developer/post?postID=v92q0fUywziFjdbla4YQ4-ZaEbgHNuk-Kzqr4ybI6GpcsX-wBpOhXBLFc9_Ng0owgxWPkmQNDsOeSZg9bewZ">lists@u...</a>]
> Sent: 10 June 2003 19:07
> To: <a
href="/group/xAP_developer/post?postID=Xf9I68FTJMmtUggPODBlXbbQe-1IB-1JDboP3G-t7j5tdICVc05Q70E6iVzr_jZAGoQYqA_95-1X3WGQ405S3aMbuM8fJ2k">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
>
>
>
> ------------------------ Yahoo! Groups Sponsor
---------------------~--
> >
> Get A Free Psychic Reading! Your Online Answer To Life's Important
> Questions.
> <a href="http://us.click.yahoo.com/Lj3uPC/Me7FAA/ySSFAA/dpFolB/TM";>http://us.click.yahoo.com/Lj3uPC/Me7FAA/ySSFAA/dpFolB/TM</a>
>
---------------------------------------------------------------------~-
> >
>
> To unsubscribe from this group, send an email to:
> <a
href="/group/xAP_developer/post?postID=PO6ZquVOlZf_hEjcPyqNqQJst230H4LP2q24yNKIISPTzM_f2o3YkmMECL822Ta_bMPF7yubrWFgPZMIjcrS8OLVlONXYZT8x7Fol2PB5ICzn-4">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>