Re: xPL announcement/description protocol -- was xPLDiag

[Mal Lansell <mal@xxxxxxxxxxx>]

I had originally thought of extending hbeats, but I opted for a new
schema because I wanted hubs to respond to, and the thought of hubs
sending hbeats sounded like it would cause problems.

However, your aguments concerning the smaller xPL devices and the
simplicity of the change are persuasive.  The hubs in any case would
need to respond with different information to the other apps (client
list for example), so perhaps a different schema for them is the
simplest approach.

Mal


Gerry Duprey wrote:

> Howdy,
>
> In addition to being used in the diagnostic you're thinking about,
this
> concept could also be used for device discovery as right now, when
> starting
> an xPL app, you have to wait around, potentially for up to 5 minutes
(or
> more!), before you hear from all clients.
>
> For a background process/device, this isn't a big deal.  But for GUI
> things,
> the user is not going to not want to have to wait 5 minutes (or more)
> after
> starting their app before they can use it.  This sort of lazy
> discovery has
> bugged me for a long time (when creating clients, which I'm spending a
> lot
> of time on lately).
>
> With something like this, you could just send the packet out and hear
> back
> from everyone.
>
> A major concern is network flooding.  If you send this sort of message
> out
> and all the xPL devices on the network respond, they will probably all
> respond at once.  Depending on how many xPL devices on the network,
you
> could flood the network, resulting in some of the responses being lost
> (and
> possibly other xPL packets being lost too).
>
> Solutions could include all devices that can would introduce a small,
> randomly determined delay before responding.  This should spread
> replies out
> and keep the network going in all but the largest installs (like
installs
> with thousands of xPL devices --  though you could segment the network
> for
> such large installs as an easy workaround in that case).
>
> Another concern is impact on simpler devices (embedded devices) that
> may not
> be able to do that calculation and may in fact not have the space to
even
> have data to fill out a message like this. So we need to make sure
> whatever
> we do has the minimum possible impact on small devices so that they
can
> easily participate, even at a reduced level.  Make the bar too high,
> and the
> xPL device makers will just skip supporting this as too complicated.
> In the
> same vein, the protocol needs to "degrade" gracefully so
that at a
> minimum,
> a simple device can just respond and identify itself when it sniffs a
> request whereas larger xPL devices can send more detailed info.
>
> ---
> That said, I've been considering the following goals:
>
>    - compatibility with existing devices
>    - reusing existing schema idioms
>    - providing for graceful degradation for devices that don't support
> this
>    - simple implementation for limited embedded devices
>    - allowance for device to participate at the level they can handle
>
> Here's a proposal that I think takes the above into account and
> attempts to
> reuse much of the existing schema stuff out there to make this as
> compatible
> as possible.
>
> Instead of creating an "about" schema class, lets re-use the
hbeat/config
> class.   This allows existing apps to be easily modified and even
allows
> those that aren't modified to still participate (albeit it more
slowly).
> The use of this allows a "graceful degradation" if the
device is
> incapable
> of sending more info.
>
> For requesting the info, we'd add the following to the hbeat/config
> schema
> class with a type "request" like this:
>
> xpl-cmnd
> {
> hop=1
> source=myVendor-myDevice.myInstance
> target=*
> }
> hbeat.request
> {
> command=request  request_details
> }
>
> This is a close fit with the existing status request mechanisms
> outlined in
> the xPL protocol doc.
>
> "request" would ask devices to send a standard heartbeat
with nothing
> else
> (this should make it easy for even tiny embedded devices to
participate).
> "request_details" would request a heartbeat as well as other
details
> about
> the device (as outlined in earlier messages) in the heartbeat
messages.
>
> Simple devices that could not add much in could just look for any
> command=
> that starts with "request" and send a heartbeat.  Really
simple devices
> could just see the hbeat.request and spit out a heartbeat.  More
advanced
> devices could distinguish between request and request_details and
respond
> appropriately.
>
> Both requests would result in an hbeat.app (or config.app) reply.  The
> hbeat.app schema already allows additional items to be included in the
> message with the standard items that are always there, regardless of
> which
> request type is sent.
>
> In terms of timing for the response, all xPL devices capable of it
would
> compute a random number of seconds, between 1 and 5, to wait and then
> send a
> response (ideally, recalculating that number each time they receive
> one of
> these requests).  For simpler devices that cannot handle the random
> calculations, they send a response immediately.  So in the first
> second, the
> simple/embedded devices that can't handle more complexity would
> respond and
> in seconds 2-6, the rest of the devices respond.  That should help
> distribute the bandwidth somewhat and still allows simple embedded
> devices
> to participate with very little code change on their behalf.
>
> To summarize the impact of this change on the protocol:
>   - hbeat.app/config.app already allow other, non-heartbeat values to
be
>     included, so there is no change there
>
>   - hbeat.request is new, but fits into the status request stuff
already
>     described in the xPL protocol document.  It can safely be ignored
>     by devices that can't handle it, though even simple devices could
>     sniff for the schema class/type and belch out a heartbeat.
>
>   - The ability to respond to such a request would be a new
requirement
>     of frameworks, but in the above proposal, it would be exceedingly
easy
>     to do so.
>
> There would be more to discuss on this including what items
specifically
> should be included  with a "request_details" (or at least
what is the
> menu
> of known items that can be used by a device -- devices may reply with
a
> subset of those items) as well as the discussion on hubs identifying
> themselves and such.
>
> Those are worthy discussion topics in their own right.  However, if
> possible, I'd like to separate the discussion on protocol changes
> (outlined
> here) from the higher level changes (outlined hopefully in other
emails).
>
> Gerry
> --
> Gerry Duprey
> Ann Arbor, MI 48103
> http://www.cdp1802.org
>
>
> xPL Links: http://www.xplproject.org.uk http://www.xplhal.com
> http://www.xpl.myby.co.uk
> To Post a Message: ukha_xpl@xxxxxxx
> To Subscribe:  ukha_xpl-subscribe@xxxxxxx
> To Unsubscribe:  ukha_xpl-unsubscribe@xxxxxxx
>
>
>
> SPONSORED LINKS
> Protocol analyzer
> <http://groups.yahoo.com/gads?t=ms&k=Protocol+analyzer&w1=Protocol+analyzer&w2=Protocol+converter&w3=Sip+protocol&w4=Tcp&w5=Protocol+analysis&w6=Protocol&c=6&s=111&.sig=QulmGKu5OpHgigyaWFXqqA>
> 	Protocol converter
> <http://groups.yahoo.com/gads?t=ms&k=Protocol+converter&w1=Protocol+analyzer&w2=Protocol+converter&w3=Sip+protocol&w4=Tcp&w5=Protocol+analysis&w6=Protocol&c=6&s=111&.sig=_Gav_2JNLbgwjsCn8RqM-w>
> 	Sip protocol
> <http://groups.yahoo.com/gads?t=ms&k=Sip+protocol&w1=Protocol+analyzer&w2=Protocol+converter&w3=Sip+protocol&w4=Tcp&w5=Protocol+analysis&w6=Protocol&c=6&s=111&.sig=d2G6YVkW-P5WBFmpuWQ3Zw>
>
> Tcp
> <http://groups.yahoo.com/gads?t=ms&k=Tcp&w1=Protocol+analyzer&w2=Protocol+converter&w3=Sip+protocol&w4=Tcp&w5=Protocol+analysis&w6=Protocol&c=6&s=111&.sig=9xqmZjMntiOfVEPLIpwKUg>
> 	Protocol analysis
> <http://groups.yahoo.com/gads?t=ms&k=Protocol+analysis&w1=Protocol+analyzer&w2=Protocol+converter&w3=Sip+protocol&w4=Tcp&w5=Protocol+analysis&w6=Protocol&c=6&s=111&.sig=j5RxaJ5TSW2NTgWhIna4qQ>
> 	Protocol
> <http://groups.yahoo.com/gads?t=ms&k=Protocol&w1=Protocol+analyzer&w2=Protocol+converter&w3=Sip+protocol&w4=Tcp&w5=Protocol+analysis&w6=Protocol&c=6&s=111&.sig=OPnkI6GadMASTgKewyeqDQ>
>
>
>
>
------------------------------------------------------------------------
> YAHOO! GROUPS LINKS
>
>     *  Visit your group "ukha_xpl
>       <http://groups.yahoo.com/group/ukha_xpl>"
on the web.
>
>     *  To unsubscribe from this group, send an email to:
>        ukha_xpl-unsubscribe@xxxxxxx
>       <mailto:ukha_xpl-unsubscribe@xxxxxxx?subject=Unsubscribe>
>
>     *  Your use of Yahoo! Groups is subject to the Yahoo! Terms of
>       Service <http://docs.yahoo.com/info/terms/>.
>
>
>
------------------------------------------------------------------------
>