Re: FW: xAP configuration protocol

[Alistair Watkins]

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.
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.

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..
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,

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
>
>