The UK Home Automation Archive

Archive Home
Group Home
Search Archive


Advanced Search

The UKHA-ARCHIVE IS CEASING OPERATIONS 31 DEC 2024


[Message Prev][Message Next][Thread Prev][Thread Next][Message Index][Thread Index]

RE: Re: Bodies in xAP Heartbeats


  • Subject: RE: Re: Bodies in xAP Heartbeats
  • From: "Patrick Lidstone (Personal e-mail)" <patrick@xxxxxxxxxxxx>
  • Date: Wed, 27 Apr 2005 17:00:12 +0100



Comments in line...

> >Kevin
> >
> >
> >To me heartbeats need to be transmitted by every app at short
> >intervals, typicaly this is every 60 seconds. Idealy the messages
> >should be short so reducing overhead and be quick to process.
> >
> >
> Can someone clarify here - are UDP packets always the same
> length ie padded with space to 1500 bytes (or whatever) or do
> they vary in length based on packet data size.  In my
> embedded app decoding two packets would take longer than one.
> Albeit one is less frequent.  In some case it just seems
> silly to  double the informational network traffic when
> frequent (once per min) info is required. Assuming this data
> is approriate for inclusion in a HB.

UDP packet payloads are not padded to 1500 bytes - they are as long as the
data they contain.

> >The Web.service messages you refer to for xAPIntranet Apps is
every
> >4.5 to 5 mins which seems to indicate a different function
> >
> >
> Really it makes external apps that have just joined the
> intranet aware of the capabilities of the application - so
> some apps have to wait upto
> 5 mins to find this.  The type of info thats is useful in
> heartbeats is not all periodic info, just a complementary set.
>
> >I guess what I am trying to say is that heartbeats are short sharp
> >simple and often and info messages are less frequent, maybe
> on demand
> >rather than regular, more verbose and potentialy more
> complex to handle
> >
> >
> >
> They cant be on demand unless the device is both a receiver
> and transmitter unfortunately. An app not capable of handling
> the info can discard it based on body name in the same way it
> would based on class name.
>
> >And of course, as you say, you do run the risk of breaking other
> >apps...
> >
> >
> >
> Well yes,   that's my bigger worry.   We have the same thing
> in reberse
> too ie headers with no bodies.
>
> >But talking of heartbeats and info messages and seeing Patricks
> >directory post, I do have a couple of of other observations or
> >proposals which I have been meaning to post for a while...
> >
> >In our distributed ha envrironment one of the difficulties I
> would see
> >is in its management. Now I dont see this as a sophisticated
> >requirement, but when you have a collection of xAP apps on a
> variety of
> >systems on your network, some of which may be headless, it is
often
> >difficult to work out exactly what you have installed.
> >
> >This is particularly true if you are trying to workout which
vendors
> >version of the app you have and which version it is, wether
> there is an
> >update, and how to contact them.
> >
> >To solve some of this, I would like to suggest that we have
> a xAP.Audit
> >schema where the apps would respond, if they were able, to an
audit
> >request with information like Appname, Appversion,
> >Appversiondate,vendor, vendorurl,currenthost

I think this is a subset of a config protocol. I think this data should
probably be stored when an app is registered with the (as yet non-existent)
xAP registry service. The reason for this is that it would allow an app's
functionality to be queried even if were dead/disconnected from the
network.

> >I think this would not need to be a regular real time app,
> just one you
> >would run when looking to gather that info
> >
> >The second part of this simple management would be a
> Watchdog program,
> >which would monitor the distributed xAP apps and report or warn
when
> >one of the Apps had stopped.

Don't know if anyone remembers, but I have a half finished VB app which
does
exactly this. If someone wants to pick ths up and run with it, I can turn
the code over to them.

> >I guess some of the xAP apps would not be critical, and would
often
> >disappear/appear on the network, but others might be more
critical.
> >
> >Some of the above might fit in nicely with viewer or it might be a
> >separate application, or someone might already have
> something similar?
> >
> >While i have been dabbling with xapax and helping out James,
> I am not
> >sure my coding skills are up to either app....
> >
> >
>
> There are some ideas sort of like this being kicked around
> currently - certainly some form of single point app
> management would be a useful tool.

I think this is essential to the wider adoption of xAP...

Patrick





xAP_Development Main Index | xAP_Development Thread Index | xAP_Development Home | Archives Home

Comments to the Webmaster are always welcomed, please use this contact form . Note that as this site is a mailing list archive, the Webmaster has no control over the contents of the messages. Comments about message content should be directed to the relevant mailing list.