RE: Standalone xPL Hub Summary

["Ian Lowe" <ian.lowe@xxxxxxxxxxxxxxxxxx>]

We could use a new type, but I don't even think it's required - just the
regular hbeats will do the trick. (and are 100% compatible with the
existing code)

One thing about that initial "rapid" heartbeat period - 1 second
is a
little fast, as IANA  frown on broadcast protocols that "hammer"
in this
way - I'm also minded of the whole Netgear SNTP debacle... It could have
consequences that are not instantly visible to us.

How about using the existing heartbeats, with a 1 message every 3
seconds for the first 30 seconds a hub is not detected, then every 30
seconds after that - whenever a hub is detected, we drop back to the
existing 1 per 5 minutes or so?

All in all, a nice elegant solution :)

I.



-----Original Message-----
From: ukha_xpl@xxxxxxx [mailto:ukha_xpl@xxxxxxx] On
Behalf Of Gerry Duprey
Sent: 14 September 2005 22:33
To: ukha_xpl@xxxxxxx
Subject: Re: [ukha_xpl] Standalone xPL Hub Summary

Howdy,

> I definitely like that last proposal. There is in fact no need for
> special packets. When a hub is up an xpl app sending a heartbeat will
> also receives

I was going to write that apps that do not send heartbeats would be in
trouble.  Except that basically, even if you are a logger (something
that never sends, just listens), you have to send a heartbeat or
something for the hub to even know you are there.  So really, no problem
there.  This would be a variation of the config.* stuff that sends
hbeats at a faster rate than normal.

For this, I think a once-a-second message would be fine. It won't flood
the network because as soon as a message is turned around, the app would
stop sending them.  Meaning that at most 1 or 2 of these messages would
get out at initial startup.

It might be nice to use a schema sub-type though so others who may get a
whiff of these packets will be able to ignore them.  Heck, the hub could
even "filter" them out and only return them to the sender (though
in
general, hubs are pretty simple critters and should probably stay that
way).

How about a hbeat.probe and config.probe schema type for these types of
messages?  I would think this would be pretty compatible with anything
out there today (which probably discard things they don't understand)
and allows others that might care about this to filter for it.

I'm really liking this idea as I see it as not only solving a myriad of
issues, but being pretty compatible with what is out there now (since
it's unlikely every xPL app would be updated at once).  Compatible and
clean.

Any thoughts on using a .probe schema type for these messages?

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



xPL Links: http://www.xplproject.org.uk http://www.xplhal.com
http://www.xpl.myby.co.uk
To Post a Message: ukha_xpl@xxxxxxx
To Subscribe:  ukha_xpl-subscribe@xxxxxxx
To Unsubscribe:  ukha_xpl-unsubscribe@xxxxxxx