Wednesday, September 5, 2012

Dynamic Bandwidth and Frequency Management

If
you have been knowing Lightstreamer for a long time, you appreciate
that it has always been particularly good at managing the bandwidth used
by the stream connection and the individual update rate of each
subscription.

In addition to heuristically spot network
congestions and adapting the data flow automatically, Lightstreamer has
always offered an API call to dynamically change the maximum bandwidth
granted to a given stream session.

The good news is
that now both Lightstreamer 4.1 and 5.0 allow you to change the maximum
frequency granted to each individual subscription on the fly.

You
will see the classic Stock-List Demo, where 15 simulated stocks push
their live market data to the browser via Lightstreamer. The demo starts
in "unlimited" mode, where neither the bandwidth nor the update
frequency are limited. This means that the data pass through
Lightstreamer and reach the browser based on the actual updates
originated by the back-end data feed, only subjected to possible
conflation in case of network issues or high latency on the physical
link.

What you can do with Lightstreamer is allocate a maximum bandwidth to that session
and have the data flow resampled and conflated dynamically to respect
the limit. Move the Max Bandwidth slider to the left, perhaps to a value
as ridiculous as 0.5 kilobits per seconds! Lightstreamer will still be
able to deliver updates to the page, thanks to the very optimized
network protocol used. Notice that when a row has a chance to be updated
(based on a round-robin algorithm), it will receive the latest
available values, not aged data. This happens thanks to "MERGE"
subscription mode, where the updates are not queued and delayed, but
resampled and conflated, without sacrificing data coherency and
consistency. Other subscription modes, with different behaviors, are
available.

But what happens exactly under the hood in
the demo? When you move the Max Bandwidth, the client will notify the
server of the new bandwidth and the server will change the update rate
on the fly, in order to respect the bandwidth limit. Usually, bandwidth
allocation is done on the server side directly, based on the user
profile. But this demos gives the final user the possibility of changing
their own bandwidth. Any change is always validated by server-side code
(within the Metadata Adapter), which can allow or deny the bandwidth
change.

Now let's move to the second slider. The Max Frequency slider sets the maximum update rate of each item
in the subscription. Again, the client will notify the server of the
new frequency limit and the server will change the update frequency on
the fly, in order to respect the frequency limit. If you set "0.5
updates/second per item", each row in the table will not receive more
than one update every two seconds, independently of the allocated
bandwidth.

Bandwidth Management and Frequency
Management are two independent tools, combined by Lightstreamer, which
you can leverage to optimized the user's experience based on a number of
variables. The cool thing is that you can apply any bandwidth and
frequency change on the fly to an existing sessions and subscription,
without requiring you to re-open a session to change its bandwidth or to
re-subscribe to an item to change its update frequency. This makes dynamic changes in settings extremely fast.
Imagine a scenario where your iPad application shows a summary of mixed
real-time data, which can be drilled down. When the user clicks to get a
detailed view of a piece of data, you might want to increase its max
update frequency (perhaps 5 times per second instead on 1 per second).
You can achieve that via a single API call and without interrupting the
data flow. If you had to change subscription to move to the detail page,
you would introduce some latency, especially on mobile networks, which
would impact on the user's experience.