Monday, July 1, 2013

HTTP Streaming with Lightstreamer

Oddmar Sandvik, a veteran consultant and software developer, wrote about his experience with HTTP Streaming using Lightstreamer on his own blog Allekonsulentene, and kindly allowed us to republish this article. Oddmar appreciated Lightstreamer in terms of performance, features, and scalability, even keeping a simple programming model in mission-critical projects.

Oddmar designed, developed, and maintained high frequency/low latency web-based financial trading solutions for DNB for about three years. With more than 1.6 million customers, DNB is Norway's largest financial services group, and one of the largest in the Nordic region in terms of market capitalisation.

Originally published on Jan. 09, 2013. Courtesy of Oddmar Sandvik.

After the introduction of AJAX technology, web users have gotten used
to information being magically updated in the browser without hitting
the refresh button. New messages, emails, alerts and of course
advertisements pop up in the background while you are doing other tasks.

This is typically done very easily in JavaScript by setting up a
timed polling function that checks every now and then if something new
has happened on the server – if so, the new information can be fetched
and the page updated asynchronously. But this is not a very satisfactory
programming model. If you want updates to happen in a timely fashion
you must poll often – burdening your server with a lot of needless
requests. On the server you may need to maintain state to determine
whether an update should be sent. It also tends to make your client code
messier and more difficult to test. Robust error handling can be
difficult to implement.

It gets worse if you need to distribute the same piece of new
information to many clients at the same time. Scalability goes down the
drain. Not to speak of applications with high frequency updates
requiring minimum latency (stock trading, betting, online games, etc) or
with a large number of simultaneous users (news sites, live sports
events). This quickly becomes an infrastructure problem, i.e. you must
think about networking, bandwidth controls, asynchronous server IO,
monitoring, and so on.

Various web streaming technologies have been in use since the late
1990s. The basic idea is to establish some sort of semi-permanent
connection from the client and allow the server to push updates back to
the clients. Techniques have included long polling and HTTP streaming
based on IFrames or multipart XMLHttpRequest. In recent years, the
WebSocket protocol (RFC 6455) and WebSocket API
have been introduced to establish a standard mechanism for full duplex
communication between a browser and a server. Support for the API is
also built into several web application frameworks, both in Java and
.NET.

So far so good. But the world of WebSockets is still not perfect. Old
browsers, proxy servers, corporate firewalls and certain mobile network
operators can still prevent clients from etablishing WebSocket
connections. If you need a very robust application, you must support
some kind of fallback mechanism. In addition, you are working with a
fairly low level API. If your needs are beyond the very simple, expect
to spend a fair bit of time implementing the plumbing you need to build
an application.

In recent years, we have been working with high frequency, low
latency market trading applications for the web. We have been using Lightstreamer,
a commercial web streaming product that also offers a free licensing
model. This has been a very stable and hassle-free piece of
infrastructure that also has made our client programming life easier. We
have operated a mission critical streaming system for nearly 3 years
with a minimum of operational trouble.

Lightstreamer offers a simple publish/subscribe client API on
different platforms. JavaScript is of course standard, but they also
have native mobile APIs (iOS, Android, Windows 8) in the commercial
licenses.

On the server side, the Lightstreamer server is a stand-alone HTTP
server implemented in Java. It is highly scalable, we have subjected it
to rigorous performance testing with very good results. We cluster the
Lightstreamer servers behind a standard HTTP load balancer and
experience rapid failover even under peak traffic if a cluster node
should be taken down.

One nice feature is “Stream-Sense”, an algorithm used by
Lightstreamer to determine the best transport for the client. By
default, it would use WebSocket, but it can fall back on HTTP streaming
or even long polling if necessary. This makes for a very robust
communication protocol that has covered all our known clients. Bandwidth
usage is also highly optimized.

Other useful features include bandwidth and frequency management,
both automatic to degrade gracefully upon network congestion, and from
the API. This allows you to e.g. allocate a maximum bandwidth to a given
session, or set a max update frequency for a specific data item. A JMX
monitoring API is available for the licensed version so you can track
all relevant performance metrics.

To connect to a given data source, you must write an adapter and
deploy this on the Lightstreamer server. The adapter API is simple to
understand and also allows you to handle session authentication and
authorization. We have implemented adapters based on both proprietary
protocols and standard JMS messaging against various back end data
sources.

Each client connects to the Lightstreamer server and subscribes to
its own set of data items. Upon subscription, they will typically get a
snapshot of the latest value. When your adapter publishes an updated
value for one data item, the Lightstreamer server will know which
clients are subscribing to this specific item and pass the update on to
each of these, using the protocol best suited for each client. The
latency overhead is minimal, even for a large number of concurrent
clients, ensuring that the update is distributed to all clients in a
fair manner within a very short period of time (depending on the
client’s own network latency, of course).

Note that Lightstreamer does not speak REST. It is also not optimized
for delivering static content. In a typical architecture, you may
therefore combine a standard REST service and front end web servers with
Lightstreamer dedicated to streaming data. (Lightstreamer also supports
two-way communications which is quite useful).

In my opinion, one huge benefit to a publish/subscribe streaming
approach is a vastly simpler programming model on the client. For
example, attach a HTML table or a JavaScript grid component to a server
side source, initiate a subscription, and off you go. We have also
successfully integrated Lighstreamer with both dojo stores and Backbone
routes, making it easy to combine with REST based services for two way
updates. In dojo, a Lightstreamer realtime store connected to a grid
using an Observer pattern makes for a very elegant and clean
integration. The client API also has good error handling mechanisms.

If you want to play around with the technology, you can get started
in minutes. Download and install the free version of Lightstreamer,
start the server and take a look at the preinstalled demos with source
code. It may well be worth the effort.