[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: RE: [obix-xml] History Push, XMPP, Long Polling
As oBIX-based systems scale, this approach can greatly reduce
network traffic – I could have really used it in a recent 100+ building
project. The historian should include some sort of ACK – If the obix
Contract is to report in once an hour, and the 9:00 report is not acknowledged,
there should be provision to report in two hours worth at 10:00… tc "A man should never be ashamed to own that he has been in
the wrong, which is but saying ... that he is wiser today than yesterday."
-- Jonathan Swift
From: Brian Frank
[mailto:brian.tridium@gmail.com] I have had a couple conversations with various
people about how oBIX should deal with lack of bi-directional connectivity.
I want to formally capture some of the various ideas in an email to the
group at large. The first idea is that it would be nice to have a standard
contract for pushing history data from a device in the field up to a server in
the sky. The existing contracts for history are structured for a server
to poll a device for history data. But if the device has no well known IP
address, it would be nice to configure the system to push its history data on
an interval basis. There are various levels of sophistication to achieve
this. Some associated use cases: - does a history have to be pre-created on
server in order to device to push data? - is there a hand-shake for the device to ask
the server what data it already has to establish what data needs to get pushed? - does oBIX standardize the contracts used to
how to configure a history for push? The simplest thing we could do that would work would be to
mimic what some vendors do today by just FTPing raw data to a server. In
this case the contract might look something like this: <obj
href=""obix:HistorySink">
<op name="sink" in="obix:HistorySinkIn"> </obj> <obj
href=""obix:HistorySinkIn">
<list name="data" of="obix:HistoryRecord"/> </obj> This would provide for a URL (of the sink op) to push a list
of HistoryRecord items. The HistorySink contract could be mixed in with
the History contract to provide start/end timestamps. I think this is the
simplest thing that could work. So I would like to discuss this approach
on our call Wed. Some other ideas generated from discussing this problem... One of the fundamental problems here is the notion of
bi-directional connectivity. Problems like this arise b/c of difficult IT
departments or network topologies where only the server has a well known IP
address. This isn't just a problem with history data synchronization, but
is a general problem for alarming, real-time data, watches, etc. One
potential solution for the generic problem might be to standardize an alternate
transport for oBIX besides HTTP which would allow one side of a connection to
establish a TCP connection which would then enable peer-to-peer communications.
The protocol which would seem the best fit for this is XMPP. So
that is another idea we might wish to discuss. Lastly, one issue which was raised earlier this week was
using oBIX in a "long poll" mode. In this mode, when a client
polls for changes to a watch, if no changes are available the server doesn't
immediately respond but rather holds open the TCP connection. See http://en.wikipedia.org/wiki/Push_technology#Long_polling for
details. I believe vendors could choose to implement this today if they
wish. But if there is a desire we could standardize it as part of the
specification. So some ideas to noodle on before our call on Wed. Brian |
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]