RE: FW: xAP configuration protocol

[Kevin Hawkins]

Hi Alistair

> -----Original Message-----
> From: Alistair Watkins [mailto:<a
href="/group/xAP_developer/post?postID=Mc6cmjYJral8CkwOPlSAuSsUNqpqTgWwei4grNRh90pUgVK_3L-ceMx2RKEk2qYSSamDAuy1STJLSStvBY3L7iAx">ukha@a...</a>]
> Sent: 12 August 2003 13:14
> To: <a
href="/group/xAP_developer/post?postID=cG-ioSvLZZwfN1H3B2MQ7Rt4V5z1w__B2bjqvcr-pQV87UZgqW9KbcQR1ymMCqCwURtglvsl2Fv3etMupME4Mp5BQCRjXYo">xAP_developer@xxxxxxx</a>
> Subject: Re: FW: [xAP_developer] xAP configuration protocol
>
> Hi,
>
> I don't really know that much about xAP or your exact 'target
> applications' but as I see it implementing service discovery is going
> to
> be a complex thing, that I know would not fit onto my micro
controllers
> that I have been experimenting with.

Indeed - and that sort of fits in with the comments about what is optional
and what is mandatory for an embedded device. The 1.2 spec takes the
approach of allowing a small core functionality to be all that is required
for compatibility with the spec but obviously as features and applications
grow for xAP the other features appear. For the total xAP experience to be
transparent then all devices would have to support all functions so this is
obviously not achievable, practical (or desireable) for embedded solutions.
Maybe though such lateral ideas as a 'helper' app for these would be a
solution - or a central repository of features that can be interrogated
over
the internet. I think we must preserve the simplicity as much as possible
for small devices. I am anxious not to have to 'raise the bar' on the base
compatibility but it would be nice within what we have already to have a
recognised 'basic' way of interrogating and setting state and configuration
data. This is really policy rather than protocol changes.
There may in time be a sufficiently capable platform - in fact
Rabbit probably is already - but I think we can leave that to a developer
who sees/requires such a feature - for example a Rabbit switch that
discovers all loads that can be controlled on a xAP network. A nice example
but one hat we shouldn't look to support in a base level requirement.
Taking
for example Ian's relay board where memory is already tight - I see the
best
route as him making available his Schemas and his I/O detail (XML ?)
somewhere such that discovery is made against that document rather than the
device itself. Maybe the device should have a link to the docs - or we need
a central repository (xAPStore) which is sort of where James is
experimenting at the moment with schemas.


> A simple way of implementing an auto-config type system would surely
be
> to
> use the heartbeat messages? It may be slow, if all the beats are
> hourly,
> but when the device turns on it can check its UUID against all the HB
> messages it receives over the hour, if it matches any it will have to
> (randomly?) pick another.

Yep - in fact Heartbeats are typically much more frequent - although
I think it's not currently a requirement that everyone sends them. There
will be some receiver only xAPp's but as a result they shouldn't need UID's
anyway . How do people feel about moving heartbeats to mandatory for all
xAP
senders ?
Another area here is the 'random' choice mechanism - probably random
isn't right but there should be a more educated or calculated option - from
how you've approached this building a table is sensible although not from a
small devices point . We could enforce all new devices use a special range
of UID's that mean 'awaiting allocation' and we could enforce all allocated
UID's to be done sequentially for examaple. But this implies a xAPp has
receive capability - maybe we have to relegate transmit only devices (to
manual config) as they can't be configured by xAP anyway.
Is a receive only device ever likely ? It couldn't be a software app
for example as it wouldn't be hub compliant ?? Transmit only are far more
likely - and problematic.

>
> Another way could be that if a device receives a heartbeat from the
> same
> UUID (but not sent from itself) it sends some sort of collision
message
> back to the UUID and the other device reconfigures..

The other device might not be receive capable though... - plus new devices
could force an older device to change their address which could disrupt
existing dependencies. Better I think to look at changing the ID of the new
device - (but it may be a transmitter only).

I was thinking last night about xAP debug/error reporting. It would
be nice to have a schema for sending debug or error messages , probably of
varying severities. These could be monitored, displayed or logged by a
central xAP application. Sort of like SNMP I guess. Now revisiting your
'collision' idea this would be a fine way of reporting that. Although the
offending 'transmit only' device couldn't be reconfigured automatically it
would instantly throw up an error.
I was going to say that the chances of getting a duplicate ID and
source address the same was very small but in reality it's probably quite
high as a new xAP initialises both. IF we had sequence numbering in the
headers of xAP messages then duplicate UID's would show almost immediately.
IN a fault condition Seq numbers could be used also to maintain
conversations with a known source even with conflicting UID's and source
names. Also perhaps as a way to identify when targeting that source (??).
You can't currently differentiate two devices by targeting when they have
the same UID and source address, for example to change the ID of one of
them
with a config message. Again maybe this points to a 'holding address' for
new xAP devices pending a real allocation. Our mechanism, in an ideal form,
should cope with duplicate instances - consider two networks that get
merged
as one where conflicts exist (not bridged or routed). We should resolve
this
gracefully if possible.


> This may not be an ideal or even the best solution, but the first bit
> would fit in with the current spec, would it not?
>
> Always willing to learn more,

We're on the sae path here !

>
> Alistair
>
> Kevin Hawkins said:
> >
> >
> >
> >
> >
> > Hi Sylvan..
> >
> > A feisty topic this one !
> >
> > We had a lot of discussion a while back (in the original Yahoo
> > Group) on exactly this topic and also an entwined one which is
device
> > discovery. This is the ability to plug devices onto a network and
> other
> > devices recognise / learn of their capabilities.
> > On the configuration issue there were many different
> suggestions, of
> > varying complexities, and lots of discussion about network
traffic
> > ramifications, which becomes very important on low speed (eg
RS232
> > transports). One of the major issues was that some devices may
only
> be
> > receivers and not able to chirp up to an 'is this uid free ?'
type
> message
> > or indeed be able to ask for a UID. This meant that we needed to
> provide a
> > listener that knew about UID's from such devices based on
heartbeats
> or
> > data. We were not sure if there should be an address management
> server
> > (along the lines of DHCP) or whether we should strive to maintain
the
> > decentralised nature of xAP. There could be issues too with
networks
> that
> > become bridged, and we anticipated this with the allocation of a
> network
> > identity within the UID. Also proposed were utilising some unique
> > identities
> > in hardware - like i-buttons, or the pre-allocation of some UID
> ranges to
> > vendors - sort of similar to MAC addresses currently using flash
RAM
> etc..
> > In the end we took the view that while networks were small and
> > private that manual management of UID's was workable and we
therefore
> > postponed the official mechanism to see how things evolved.
Probably
> this
> > still holds but very soon it is going to become an issue again.
So I
> would
> > welcome the revival of the discussion and some proposals -
however we
> need
> > a
> > champion :-) and it is a surprisingly awkward area, really only
> because
> > there are lots of solutions and you have to trade features vs
> complexity.
> > Would you feel like stepping up to the mark on this one ?? This
group
> > would
> > form the basis of the discussion.
> > Additionally a few people, Patrick I think particularly, are
> using
> > some configuration xAP messages to allow setting of fundamental
xAP
> > configuration data (source addresses, heartbeat interval and
UID). We
> > could
> > do with formalising the Schemas here so we have some communality
-
> and
> > this
> > would then put in place a layer for higher level policy that is
> needed for
> > the configuration / discovery issues.
> > I run about a dozen xAPp instances here and the network sees
> around
> > 100 different UID's ( I use sub addressing for the C-Bus stuff
which
> > generates a unique UID per switched load ). I haven't experienced
any
> > difficulties with UID - except hubs without one and the
occasional
> > DEADBEEF's ;-). Indeed having conflicting UID's doesn't break the
> network
> > (
> > a design strength) however it makes abbreviated source
recognition ,
> and
> > cache applications fail - so it shouldn't be allowed.
> >
> > Kevin
> >
> >
>
>
> ------------------------ Yahoo! Groups Sponsor
---------------------~--
> >
> Buy Ink Cartridges or Refill Kits for Your HP, Epson, Canon or Lexmark
> Printer at Myinks.com. Free s/h on orders $50 or more to the US
&amp;
> Canada. <a href="http://www.c1tracking.com/l.asp?cid=5511";>http://www.c1tracking.com/l.asp?cid=5511</a>
> <a href="http://us.click.yahoo.com/l.m7sD/LIdGAA/qnsNAA/dpFolB/TM";>http://us.click.yahoo.com/l.m7sD/LIdGAA/qnsNAA/dpFolB/TM</a>
>
---------------------------------------------------------------------~-
> >
>
> To unsubscribe from this group, send an email to:
> <a
href="/group/xAP_developer/post?postID=Yq2oNFQBoRZKtsMeEU6cx2WBbtyEVyvE_IZwYYsoQAUTMKwaOPmmH6QPeSnRYY1qLKYMjzlb9UERtmxQim82Gbxkqdcxjv3xPkvCNMh1rPnvnQ8">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>