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