Re: Re: Hub Operations

["Michael McSharry" <mcs101main@xxxxxxx>]

------=_NextPart_000_0006_01C4B436.80CC1AB0
Content-Type: text/plain;
charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

In flight-critical applications the decision time for failure detection
and=
reconfiguration is typically under one second.  The speed of my house, how=
ever is measured in geological time as it is attached to the North
American=
tetonic plate.  A two minute period of silence will hardly ever be noticed=
and it sure beats the alternative of an indefinite period of silence.  Fro=
m an implementation perspective the hub is the easiest thing to manage in
W=
indows since the hard work of actually allocating the port to exactly one
u=
ser is handled by the OS.  A backup hub simply needs to try to acquire
3639=
periodically and when successful it just keeps running with it in the role=
of a hub.  In the Role schema I proposed for this awhile back,  this new h=
ub would simply change it's role status from backup to primary and another
=
instance of the hub app spawned.  The new instance would start as a backup
=
since it would not be successful at acquiring 3639.

----- Original Message -----=20
From: Patrick Lidstone (Personal e-mail)=20
To: xAP_developer@xxxxxxx=20
Sent: Saturday, October 16, 2004 9:46 AM
Subject: RE: [xAP_developer] Re: Hub Operations


David,

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