Lightstreamer is a Java based push / streaming engine that delivers real-time textual data both to Web browsers and desktop applications. When using browsers as a client, nothing is installed or downloaded (no applets or ActiveX, but only pure HTML / JavaScript). This is something similar to the AJAX approach. But while the classic AJAX approach is based on polling to retrieve new data, Lightstreamer implements a "streaming AJAX" paradigm, because the updates are pushed by the server in an asynchronous fashion.

In version 3.1 the new StreamSense feature has been introduced for scenarios where a network infrastructure blocks any form of streaming to the client. With StreamSense each Lightstreamer Web Client can automatically detect if the streaming mode is unsupported and then switch to the Smart Polling mode. In this case (and only for those individual clients) periodic updating is used with a highly optimized AJAX like approach.

Lightstreamer Server implements several mechanisms to optimize the data transmission on heterogeneous networks. It is possible to allocate a maximum bandwidth for each streaming channel, along with the use of Adaptive Streaming that detects any network congestion in order to dynamically throttle the data.

In version 3.1 the new StreamSense feature has been introduced for scenarios where a network infrastructure blocks any form of streaming to the client. With StreamSense each Lightstreamer Web Client can automatically detect if the streaming mode is unsupported and then switch to the Smart Polling mode. In this case (and only for those individual clients) periodic updating is used with a highly optimized AJAX like approach.

Lightstreamer is currently used by banks and financial platform providers to deliver real-time market data to any type of client and many other applications are under development.

Several on-line demos are freely accessible and a white paper is available for download.

FWIW we've had Ajax support for some time in ActiveMQ for streaming of real time data to web browsers using JavaScript..
http://activemq.org/Ajax

We've recently changed our Ajax demos to reuse the OpenRico Ajax library (http://openrico.org/). It takes significant effort to ensure JavaScript runs on all versions of browsers so standardising on a good Ajax library is a good thing - and certainly OpenRico seems very good & well used. (I'm glad we no longer have to test our own XmlHttpRequest JavaScript on many browsers :)


So I wonder, how does Lightstreamer's use of JavaScript differ from say OpenRico or any of the other standard Ajax libraries use of JavaScript? Are you using XmlHttpRequest under the covers or explicitly using sockets using (say) the Mozilla-specific socket libraries?

When using OpenRico with ActiveMQ, OpenRico is performing HTTP GETs using XmlHttpRequest which may block until they receive data or timeout. So logically its a push; though physically the JavaScript is polling of sorts - though with delays between polls where data can be pushed.

With the use of HTTP batching, keep alive sockets and letting the server side block and timeout if no messages are available, the effect is very much like a push - though in reality Ajax can only really pull.

Is there some new JavaScript trick your aware of to get real pull without really doing lots of HTTP GETs under the covers? :)

James
LogicBlaze

Strachannie why u always trying to advertise inactivemq ? j00 wanting to stick your little genitalia everywhere so people can tugging and you tug back. now please going back to your hole

James, look at HTTP 1.1's KEEP ALIVE capabilities.....

James, look at HTTP 1.1's KEEP ALIVE capabilities.....

I mentioned keep alive & HTTP batching in my reply :) Even with keep alive its still technically a pull, though admittedly its reusing the same socket etc.

James
LogicBlaze

Check out:

http://www.icesoft.com/products/icefaces.html

This was demo'ed at JavaOne, looks really good. I thought Lightstreamer was exactly the same thing.

I agree with your considerations, James. Anyhow Lightstreamer is not based on XmlHttpRequest, but on JavaScript streaming techniques. This is why I've used the term "streaming AJAX", to refer to a paradigm that have some differences with the "classic AJAX" paradigm.

Basically AJAX, when used to update the data displayed in a page, is a polling technique, even if it can be used to simulate push by blocking the request as you correctly suggests.

I think that the "streaming AJAX" approach has a couple of advantages over the classic one:

- Zero latency between the generation of new data and its delivery to the final client even at high rates. No polling period has to be waited for to see fresh data, so that high-frequency real-time solutions are possible. Even with the "simulated push" AJAX-based approach, it is not possible to send high frequency updates, beacuse a full round trip is necessary for each update.

- Full control over bandwidth usage. A permanent stream connection is kept open for each client. When no fresh data is available on the server, no unnecessary traffic is generated (except for low-frequency and small-sized keep-alive packets). Furthermore on the server side several bandwidth management and filtering mechanisms can be implemented to offer a good QoS. With a polling technique it's very difficult to keep a good control over the performance of the connection across several requests.
For example, Lightstreamer has an "adaptive streaming" mechanism that detects network congestions, so that it can slow down the update frequency when the available bandwidth shrinks. This is very useful to push data on mobile networks, in order to adapt heuristically to the actual conditions of the infrastructure.

Alessandro

Thanks for the explanation Alessandro.

Both mechanisms, pushlet style and Ajax (XmlHttpRequest) style are fairy similar from 30,000 feet.

Actually, with HTTP keep alive and HTTP pipelining, you can completely avoid the latency issue with Ajax with XmlHttpRequest (as the next request can be sent in advance).

Also with keep alive sockets you've full control over bandwidth in pretty much the same way you suggest; since you can block the request on the server until there is data available - so the effect is you can push data as soon as its available to the client and the server is in full control of what data to send and when.

So in terms of latency and bandwidth control I think both mechanisms work quite similarly really.

Ajax is certainly a little cleaner to use on the client side; as the client can decide when to make another request and so forth (and can deal with multiple requests from different URLs etc). Its also easier to handle auto-reconnection if a firewall/router closes a socket. Also the Ajax/XmlHttpRequest does work a little better with existing web infrastructure, since each request is working with individual HTTP requests which can pass through routers and so forth easier.

The main difference though seems to be, do you want your server side to send around XML packets, or does the server side have to understand JavaScript of the actual page that it is sending to. The nice thing about the Ajax approach is its a bit of a looser coupling; the server sends XML payloads and the web pages can do what they like with it; rather than forcing the client side to use a specific JavaScript library etc.

e.g. using the Ajax approach you can use any Ajax library on the client side and any page can use the server. With a pushlet approach, the data the server sends is often coupled to a specific client side JavaScript library.

We switched our ActiveMQ demos from using our own JavaScript library to using OpenRico with no particular change on the server side - since its ultimately HTTP in both cases. I'm sure we could use DojoToolkit too if need be. That flexibility of the client side to do whatever it wants can help have a more loosly coupled system.

As JavaScript becomes more powerful (e.g. folks are already building SOAP stacks, XSLT and template engines on the client side) I see folks moving more in the XmlHttpRequest direction to make a more SOA style Ajax messaging approach.

James
LogicBlaze

I've already looked at pushlets to do push via html/js http://www.pushlets.com/. Has anyone looked at both to compare? I know pushlets are mature (the site says 5 years old) and have been used in commercial contexts.

Dislaimer: The pushlet project does not provide/include an AJAX-ready framework, but it contains a simple ad hoc example on how to do AJAX.

sv

I've already looked at pushlets to do push via html/js http://www.pushlets.com/. Has anyone looked at both to compare? I know pushlets are mature (the site says 5 years old) and have been used in commercial contexts.

There's a comparison here (the bottom half of the page).

You could argue Pushlets are kinda Ajax since they are JavaScript; though I think folks tend to assume Ajax means the use of XmlHttpRequest.

James
LogicBlaze

though I think folks tend to assume Ajax means the use of XmlHttpRequest.JamesLogicBlaze

I've seen at least one project which "degrades" to hidden frames for doing Ajax stuff whenever XmlHttpRequest is not available, for example in older browsers.

Regards,
Henrique Steckelberg

though I think folks tend to assume Ajax means the use of XmlHttpRequest.JamesLogicBlaze

I've seen at least one project which "degrades" to hidden frames for doing Ajax stuff whenever XmlHttpRequest is not available, for example in older browsers.Regards,Henrique Steckelberg

Agreed. Pushlets can crash some older browsers and XmlHttpRequest is not always supported on old browsers - so I guess good web sites need to make sure they can operate without either :).

One of the worst things about making web applications is old browsers...

James
LogicBlaze

I've seen at least one project which "degrades" to hidden frames for doing Ajax stuff whenever XmlHttpRequest is not available, for example in older browsers.Regards,Henrique Steckelberg

Yes...XmlHttpRequest is very easy to hack with, but not so capable by itself. You need a mix of browser communication "transports" to cover all the bases: server push, file uploads, caching, etc.

The fail-over to eg hidden frames is sometimes for old browsers, but usually because ActiveX has been disabled in Internet Explorer, for security.

Cheers-

Jeff Dill
www.SmartClient.com