Re: xPL announcement/description protocol -- was xPLDiag

["Mal Lansell" <mal@xxxxxxxxxxx>]

--- In ukha_xpl@xxxxxxx, "Tony Tofts" <tony@x> wrote:
> > Even if an app is
> > already configured and starts straight away, if it starts
> > before the hub it could be up to 9 minutes before the hub
> > receives the next hbeat from the app and starts sending xPL
> > messages to it - and that is not good.
>
> I agree it's not good, but I also think it's incorrect?
>
> 1) if hub starts after the app, the next hbeat is at most 5
minutes away (so
> 5 minutes max wait, assuming default interval)?

You can't assume default interval - if someone configures it to the
maximum 9 minutes, then it could take up to 9 minutes, like I said.

>
> 2) hubs are mean't to restore the list of known clients on
startup, so other
> than a new app (which would be in config mode anyway) they should
broadcast
> to all previously known clients? Ok there are exceptions, e.g. if
app closes
> first I guess this may get removed from the hub list - so I feel a
more
> robust method would be for hubs not to delete directly on
hbeat.end, but
> flag it and delete on expiry or hub exit (if this is sooner)?
>

I don't see how that would make anything more robust - if the client
exits before the hub, which may well happen when the system is shut
down, it still gets deleted from the list.

Anyway, I thought saving the client list was just for the V3 hubs -
and  only because they needed to share that information to enable a
seamless changeover.

IMO, all apps should send .end before closing - which would render
saving a client list pointless in a standalone-hub system.

The most robust system to me is the quick hbeat one - it doesn't
matter what the start order is, or what the client list was when the
hub last exited, within a few seconds everyone is discovered and
running normally, and the need for saving/loading a client list is
completely eliminated.

Mal