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




turner228 wrote:

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

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

>
>(The other) Kevin
>
>
>
>
>
>
Kevin (not the other)





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.