Three layers of abstraction build up the powerful networking engine of the Lightstreamer Server.

The multichannel transport layer of Lightstreamer implements a reliable network transport that works in any situation. The StreamSense mechanism implements a fast detection of the best transport on a per-client basis, with a sequence of automatic fallbacks. If WebSockets are not supported by a network intermediary, HTTP Streaming is automatically employed, which in most cases provides the same performance of WebSockets. If HTTP Streaming is blocked by some older proxy/antivirus, HTTP Long Polling is used, which is an extremely optimized form of polling (nothing to do with traditional polling).

Whatever is the selected transport, a high-performance bidirectional channel is provided, with in-order guaranteed delivery with automatic batching even for messages sent from the clients to server.

In addition to web transports, Lightstreamer supports native push notifications to mobile clients. No extra development on the server side is necessary: messages originated from the Data Adapter can use both the streaming channel and the push notification channel. Apple APNs for iOS and Google GCM for Android are fully supported.

Lightstreamer implements a pub-sub paradigm, to decouple message producers from message consumers.

A client subscribes to items (the basic piece of information) while specifying a schema (a set of fields for each item). When an item is subscribed to by a client for the first time, the subscription is propagated to the Data Adapter, which can start publishing updates for that item. Any subsequent client subscribing to the same item does not cause any new request to the Data Adapter. When the last client unsubscribes from that item, the Data Adapter is notified it can stop publishing updates for that item. This is called publish-on-demand.

Thanks to publish-on-demand, no data needs to be produced when no actual recipient exists, saving on systems resources.

Any message routing scenario is supported. From unicasting (where a message targets only one client), to broadcasting (where a message reaches all the clients), passing through multicasting (where a message reaches a group of clients). Broadcast, multicast, and unicast subscriptions can be freely mixed as part of the same client session.

Lightstreamer implements an asymmetric pub-sub paradigm. The publishers are on the server side (connected to the Data Adapters) and the subscribers are on the client side. This highly optimizes the cases where there is some massive publishing from back-end data feeds. In many scenarios, the data feed is completely different from the data consumer (due to topology, to protocol, or to the business model). But clients can still publish data, by sending direct messages to the Data Adapter (intermediated by the Metadata Adapter for security reasons).

This way, the Data Adapter keeps the responsibility of publishing the actual updates for each item. In some cases, the Data Adapter will want to validate, reformat, and process the data before publishing it. This is the extreme flexibility provided by the asymmetric pub-sub model, compared to traditional symmetric pub-sub systems, where publisher and subscribers are all peers (and some complex ESB might be needed to validate and adapt the data flows).

Based on the nature of the data, series of updates to an item can be filtered, to reduce their frequency, via queueing, resampling, and conflation. For each subscription of each client, Lightstreamer allows to define how data can be filtered, with several parameters. Filtering is then applied on the fly to the data stream based on a number of static and dynamic conditions.

With bandwidth allocation, for each client a maximum bandwidth can be allocated to its multiplexed streaming connection. Lightstreamer guarantees that such max bandwidth is never exceeded. Max bandwidth can even be changed dynamically during the life of a client session.

With frequency allocation, for each subscription of each client, a maximum update frequency (message rate) can be allocated. Lightstreamer guarantees that such max frequency is never exceeded. Max frequency can even be changed dynamically during the life of a client session.

With real bandwidth detection, Internet congestions are detected by Lightstreamer and the actual available bandwidth at any point in time for each client is estimated.

Lightstreamer heuristically combines all these categories of variables to dynamically throttle the data flow by applying the proper filtering algorithms to each subscription for each client.

Example: Suppose a mobile client connected over a tiny-bandwidth network with terrible packet loss and a desktop client connected with a broadband connection subscribe to the same item. This item might contain the 3D coordinates of a user in a multiplayer game, or the telemetry data of an airplane, or the prices of a financial instrument. In all the cases, each client will receive an amount of updates compatible with its network capacity. The first user above will probably receive less updates per second than the second user. But both will receive up-to-date data, not aged data that stacked up in a queue. Resampling done on the fly for each individual user is one of the most powerful features of Lightstreamer. To learn more on this and other network optimizations provided by Lightstreamer, you can check out this article (even if you are not interested in gaming applications).

In addition to the above, Lightstreamer implements several other network optimizations.

Batching and TCP packet optimization: Data is aggregated efficiently within TCP packet, with a configurable trade-off between latency and overhead reduction, overriding Nagle's algorithm.

Lightweight protocol: A position-based protocol with negligible overhead is used to transfer data (no JSON, no XML, or other protocols with verbose metadata redundancy).

Delta delivery For subsequent updates to an item, only the actually changed fields (delta) are sent.

Multiple subscription modes: Lightstreamer provides four different subscription modes, called Merge, Command, Distinct, and Raw. They offer different features and abstractions, making it very easy to map any real-time data model onto Lightstreamer items.