xPL announcement/description protocol -- was xPLDiag

[Gerry Duprey <gerry@xxxxxxxxxxx>]

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