Latency is defined as, "The time interval between initiating a query, transmission, or process, and receiving or detecting the results."
The goal of this guide is to discuss options for minimizing the latency experienced between Notehub.io and a given Notecard. Minimizing latency typically comes at a trade-off in power draw (and potentially data usage - depending on your use case). However, when configured correctly, the Notecard will be opened to a whole new realm of possibilities.
When modeling the flow of information between a Notecard and Notehub.io, you must first take into consideration the following maxim...
All synchronization operations are initiated from the device in a "push/pull" manner; the service is passive.
When you begin to think of a transaction in this manner, the capabilities and limitations of operations will become obvious. As a result, you will gain an intuitive understanding of what steps must occur in order to achieve your desired outcome.
Above, the Notecard is operating in continuous mode with sync set to
true. This configuration initiates two separate, simultaneous connections;
one dedicated to Note delivery and the other dedicated to notifications.
As previously stated, any time the Notecard and Notehub communicate, that
communication must be initiated by the Notecard. Therefore, in order for the
Notecard to be gather new information from Notehub.io, the Notecard would need
to issue requests to Notehub.io. The frequency of this polling request interval
is specified by using the inbound parameter.
Ideally, you wish for the synchronization to occur as close as possible to the
moment any data changes. In order to minimize latency by using the inbound
parameter alone, the interval must be specified to be as small as possible.
However, doing so would ultimately result in great inefficiencies for both data
usage and power draw.
Fortunately, this limitation can be overcome by the introduction of a secondary communication channel, one dedicated exclusively to notifications.
Proving Notehub.io with a mechanism to alert the Notecard of new Notes, while still initiating the transaction from the Notecard itself, has a more elegant and simple solution than you may have guessed...
When sync is set to true, the Notecard establishes a secondary connection,
one dedicated to the notification of new Notes. This connection utilizes HTTP
long polling to request the set of changes, and the server will only respond
once changes become available. Now, when the Notecard becomes aware of any new
Notes, it can immediately synchronize the Note queues on the primary connection.
req: "hub.set", mode: "continuous", sync: true, inbound: <Number: polling interval in minutes>
Once mode is set to continuous, a continuous connection is established
between the Notecard and Notehub.io. Maintaining a continuous connection
requires significantly more power than polling at a periodic interval, but the
Notecard will have much faster response times as a result. A continuous
connection prevents the Notecard from being required to power on,
connect to a cellular tower (or a Wi-Fi access point for the Wi-Fi Notecard),
and open a connection to Notehub.io with each
transaction. All told, this can minimize the amount of data required for each
transaction, as well as the time required to send messages in either direction.
When sync is set to true, a secondary connection is established with the
express purpose of allowing Notehub.io to signal that new data has arrived for
the Notecard to process.
When Notes are received on Notehub.io, Notehub will send a list of the filenames that were modified to the Notecard. Then, the Notecard will issue a request for changes over the primary connection, and pull the new Notes from Notehub.io to the Notecard. Once they have arrived on the Notecard, then they can be operated on by your program.
If your application can benefit from knowing as soon as information becomes
available on Notehub.io, then utilizing sync:true is the most efficient way
to expedite Note arrival. Depending on your desired polling interval, operating
in this manner can even result in power and data savings.
Inbound polling will force a synchronization at the specified interval, regardless of whether or not data is known to be queued on Notehub.io.
Theoretically, inbound would have no value when sync:true is enabled.
However, in practice, inbound is a necessary evil, and must be used as a
backstop to safeguard against connection failures or any other gaps in the
secondary, notification connection. Scheduling an inbound interval provides a
brute force guarantee to ensure queued data will be never be older than the
specified interval.
Each inbound event will necessarily require a connection with Notehub.io, so it can perform a polling request. This transaction will consume both energy and data at the specified polling interval (i.e. for each transaction), so any interval should be selected with care and tailored to the needs of the application.
Due to the fact the Notecard is the originator of all transactions between the Notecard and Notehub.io, it stands to reason the outbound operations should be considered separately from the inbound operations. Therefore, minimizing the latency on an outbound transaction is much more simple, because the Notecard controls the connection.
req: "note.add", ..., sync: true
When sync is set to true, the Notecard will immediately send the queued
changes to Notehub.io. Otherwise, when not specified, or set to false, the
Notecard will wait for the outbound interval to send the request.
noteUnlike inbound transactions, there is no need to specify an outbound interval
as a fail-safe. This is due to the fact the transaction does not rely on a
network or external signal to indicate whether or not it should attempt to
synchronize queued Notes.
