The UK Home Automation Archive

Archive Home
Group Home
Search Archive


Advanced Search

The UKHA-ARCHIVE IS CEASING OPERATIONS 31 DEC 2024


[Message Prev][Message Next][Thread Prev][Thread Next][Message Index][Thread Index]

RE: Re: Hub Operations


  • Subject: RE: Re: Hub Operations
  • From: "Patrick Lidstone \(Personal e-mail\)" <patrick@xxxxxxxxxxxx>
  • Date: Sat, 16 Oct 2004 17:46:32 +0100


David,

> This goes right back to installability and usability for non-experts.
>
> Therefore, one of several things needs to be done.
>
> a) Nothing, everything is fine as it stands.
>
> b) Every application must be hub capable, which then means we
> have a plethora of applications most of which have
> real-world-untested hubs in them.  This still doesnt solve
> the "vanishing hub" problem.
>
> b1) A series of platform specific "hub" components built
that
> are of compact size (ie for Windows doesnt require MS .Net
> framework and xFx), and free from commercial use
> restrictions, and are thouroughly tested, and it is
> recommended in the strongest terms that all applications use
> them.  This still doesnt solve the "vanishing hub" problem.
>
> c) Hubs are mandatory, and applications dont attempt to bind
> to 3639.  For reliable operation, a mechanism to detect the
> presence is required, as well as a solution to the vanishing
> hub problem.

Wise words as always :-)

Another issue with hub aware applications (which you alluded to, but is
worth mentioning explicitly) is that it could lead to hard-to-trace
bugs, since the hub you use would actually depend on the order in which
applications are started - and this can be difficult to determine on a
windows based system.

Michael talked about redundancy in a previous post. The idea that other
apps should somehow detect the failure of a hub and assume the role of a
hub is fraught with race-condition problems and is totally non-trivial
to solve. Even if it was possible, the protocol as it currently stands
does not provide any means to force applications to re-register with a
new hub, so messages could potentially be dropped for two heartbeat
periods. Not very nice at all!

Personally, I'd favour option (c), and we simply treat the hub as
infrastructure and install it as a service/daemon so that it's always
there and always available. Like all other components, a hub should
generate heartbeats, so monitoring the health of a hub shouldn't be
impossibly difficult.

Patrick





xAP_Development Main Index | xAP_Development Thread Index | xAP_Development Home | Archives Home

Comments to the Webmaster are always welcomed, please use this contact form . Note that as this site is a mailing list archive, the Webmaster has no control over the contents of the messages. Comments about message content should be directed to the relevant mailing list.