Re: Standalone xPL Hub Summary

[Gerry Duprey <gerry@xxxxxxxxxxx>]

Howdy,

> How about apps *don't* try to bind to 3865 to see if a hub is there -
> they don't need to. If we are making a pre-existing hub mandatory for
> xPL on a PC, they don't need to check for it's presence.
>
> That means the app can't exit immediately when no hub is there (as it
> can't tell) - however, this probably makes it a little more tolerant
of
> start order. It doesn't really matter which service or app starts
first
> if none of them even *touch* 3865, and they all just assume that a hub
> is present.

I could see this, though I can imagine folks who don't know better
wondering
why they are app is not running.

The thing that concerns me though is the time it'll take to
"register" the
app with the hub (until hub sees a new client, it won't start forwarding
packets to it).  If a xPL program only broadcasts it's heartbeat at startup
and then every 5 minutes there after, it could be 4:59 (worst case) before
an xPL app that start before the hub starts receiving messages from the
hub.

Of course, we could use a slight variation of what Paul suggested in the
"ping" stuff.  Basically, once the app starts (no polling port
3865), it
sends some sort of simple xPL message out every second until it hears that
message back from itself.  When it does, it knows the hub is running and
falls back to normal hbeat mode. If it doesn't hear something back in  a
certain period of time say 30 seconds), it can then determine the hub was
not present and tell the user it's missing.  It could still keep trying
after that, just maybe we advise the user there may be something up after a
30 seconds.

This would seem to address the race condition, the startup order condition,
the registration time for a later-starting hub and the (eventual) detection
of no hub condition by the app.

Gerry


--
Gerry Duprey
Ann Arbor, MI 48103
http://www.cdp1802.org