CommTech Talks: Lightstreamer (A. Alinone)

Alessandro Alinone
Co-CEO and CTO

Agenda
● Background on Weswit/Lightstreamer

● Some Real-Time Web use cases based on
Lightstreamer

● Push technology and the Real-Time Web:
history and techniques

● Lightstreamer: architecture, features, and
live examples

Weswit named "Cool
Vendor" by Gartner
Gartner, "Cool Vendors in Application
and Integration Platforms, 2012", by
Massimo Pezzini and Jess Thompson,
11 April 2012.

Cool Vendor Report 2012 Cites Weswit, with its Lightstreamer Product, as
Innovative, Impactful and Intriguing in the Area of Application and Integration
Platforms.
"Web streaming is an emerging form of MOM aimed at enabling back-end applications to send real-time
messages over the public Internet, typically to large numbers (up to millions) of mobile or stationary endpoints,
according to a publish-and-subscribe model". When analyzing 'Who should care' the report goes on to explain:
"ISVs, SIs and cloud service providers that require efficient, low-latency and scalable publish-and-subscribe
data distribution to mobile and Web-based endpoints should look at Web-streaming technologies as a way to
add value to their offerings by enabling reliable and relatively easy-to implement connectivity."
Disclaimer: Gartner does not endorse any vendor, product or service depicted in its research publications, and does not advise technology users to select only those vendors with
the highest ratings. Gartner research publications consist of the opinions of Gartner's research organization and should not be construed as statements of fact. Gartner disclaims all
warranties, expressed or implied, with respect to this research, including any warranties of merchantability or fitness for a particular purpose.

The Real-Time Web
Information is delivered on the fly as soon as it
is generated. Web pages and mobile app
screens update in real time.
Many application domains are taking benefit from the Real-Time Web:

● Financial services: Online trading platforms for capital markets, live price
dissemination, order submission, portfolio management, spread betting
● Aerospace and Defense: Web telemetry of space vehicles, satellites, and
aircrafts, Web-based management of airport operations
● Media: social TV, second screen, sports event live data
● Gaming: Online casinos, sports betting, online multiplayer video games
● Transportation and Logistics: live tracking, supply chain monitoring
● Alerting: Emergency mass notification systems
● And many others: Energy smart grids, social networks, online
collaboration tools, online auctions, systems monitoring, e-learning, ...

NASA: International Space
Station live http://spacestationlive.jsc.nasa.gov

America's Cup: live race
telemetry http://noticeboard.americascup.com/Race-Data

Morgan Stanley Matrix: the
trading floor
http://www.morganstanley.com/matrixinfo

IG Group: spread betting
and CFDs http://www.igindex.co.uk

bwin.party: sports betting,
online gaming http://www.bwinparty.com

RAI: Social TV http://www.rai.it

X Factor: remote clapping
and voting http://www.rai.it

What is push technology?
● "Push technology" term coined in 1996
● Information delivery from server to client

● Push vs. pull
● Asynchronous vs. synchronous
● Publish and subscribe

● Email is one of the oldest push systems
● Push technology is the base of the Real-
Time Web

The three waves of push
technology
● 1996-2000: First wave (Webcasting)
Coarse-grained daily updates

● 2000-2012: Second wave (Comet)
Polling, long polling, streaming

● 2012 onwards: Third wave (WebSockets)
Full-duplex bidirectional streaming

An example to help
illustrate
A temperature and
humidity sensor must send
data to a Web browser
(sensor example).
Web
Let's see how this might
have been done in the
history of push technology.

First wave: Webcasting
● Webcasting, narrowcasting, channeling, …
● 1996-1998: 30 players in the market
(including Pointcast, Microsoft, Netscape)
● 2000: The first wave is dead
● Very coarse-grained, not real-time at all, and
bandwidth-intensive
○ Someone compared the first wave of push
technology to having giant heaps of newspapers
dumped on your doorstep every morning...
● Sensor example: Series of temperature and
humidity values of the day before

Second wave: from polling
to Comet
● 2000: Online trading systems require push
● Requirements:
○ Fine-grained updates
○ Real-time updates (low latency)
● Very first players: Lightstreamer, Caplin,
Pushlets, KnowNow
● Technology means:
○ Front-end: HTML and/or Java applets
○ Transport techniques: Ajax polling, Comet long
polling, and Comet streaming

Ajax and Comet
2005: Ajax (Asynchronous JavaScript and XML)

Jesse James
Garrett

2006: Comet

Alex
Russell

HTTP/1.1 - Hypertext
Transfer Protocol
Response
HTTP/1.1 200 OK
Request Cache-Control: private, no-cache, no-store, must-revalidate
Expires: Sat, 01 Jan 2000 00:00:00 GMT
P3P: CP="Facebook does not have a P3P policy. Learn why here:
http://fb.me/p3p"
Response Pragma: no-cache
X-Content-Type-Options: nosniff
X-Frame-Options: DENY
X-XSS-Protection: 1; mode=block
Set-Cookie: reg_ext_ref=deleted; expires=Thu, 01-Jan-1970 00:00:
01 GMT; path=/; domain=.facebook.com
Set-Cookie: wd=deleted; expires=Thu, 01-Jan-1970 00:00:01 GMT;
Request path=/; domain=.facebook.com; httponly
Content-Encoding: gzip
GET / HTTP/1.1 Content-Type: text/html; charset=utf-8
Host: www.facebook.com X-FB-Debug:
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:16.0) 4wzuaiMEh5R1tzwT7CBNVncjMl1zLu3fmz4CvMLu+UQ=
Gecko/20100101 Firefox/16.0 Date: Tue, 30 Oct 2012 14:16:12 GMT
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*; Transfer-Encoding: chunked
q=0.8 Connection: keep-alive
Accept-Language: en-US,en;q=0.5
Accept-Encoding: gzip, deflate 2d2e
Connection: keep-alive
Cookie: datr=IeCPUJWOBWaU0LrmpOTOC-YX; ...........}[o#Y..{..lNO..-..[...u.J...R.&.L&........j....0.'...a.afoX.^`.{...3.`.
reg_fb_gate=http%3A%2F%2Fwww.facebook.com%2F; {.....?._..L&/.....w.]...d.s.....'"...7.6N..[R...k_..?..
reg_fb_ref=http%3A%2F%2Fwww.facebook.com%2F; COMPRESSED CONTENT..........................................
wd=1080x1281
Cache-Control: max-age=0

Full page refresh
Refresh 1 Typical issues:
wait... wait... ● Low update frequency; no
real time
● High bandwidth usage
Refresh 2 ● High load on Web server
wait... wait...
Sensor example: for each
refresh, the full HTML page
Refresh 3 with the current values is
wait... wait... retrieved

User Browser Server

Ajax polling
Typical issues:
Action 1 wait... ● Low update frequency; no
real time
● High bandwidth usage (but
lower than page refresh)
wait... ● High load on Web server
Advantages:
● User interface is never
blocked
Action 2 wait...
Sensor example: for each poll,
the current values are retrieved

User Browser Server

Comet long polling
Typical issues:
Action 1 wait... ● Medium update frequency;
near real time
● Medium bandwidth usage
(HTTP headers still present
wait... in each round-trip cycle)
● High load on Web server
Advantages:
wait... ● User interface is never
Action 2 blocked
● Low latency on low-
frequency events

User Browser Server

Comet long polling (2)
Sensor example: for each poll,
Action 1
the new values are retrieved
wait...
only when they become
available. Otherwise, the
request is kept pending (long
poll)
wait...

wait...
Action 2

User Browser Server

Comet streaming
Typical issues:
Action 1 ● May be blocked by some
anti-virus software
mounted on proxy servers
Advantages:
● High update frequency; low
latency; true real time
● Low bandwidth usage (very
little overhead)
Action 2 ● Low load on the network
infrastructure

User Browser Server

Comet streaming (2)
Possible techniques:
Action 1 ● Iframe streaming
● XHR streaming
● Flash streaming
● Server-Sent Events

Sensor example: the server
keeps pushing real-time
updates as they become
Action 2 available, whatever is the
frequency, without
request/response round trips
from the client
User Browser Server

Third wave: WebSockets
● WebSocket protocol:
○ 2007: First draft
○ December 2011: IETF RFC 6455
● WebSocket API:
○ 2009: First draft
○ 2011: First W3C Candidate Recommendation
○ 2012: Second W3C Candidate Recommendation
● Browser support:
○ Early support by Firefox and Chrome
○ Subsequent support by Safari and Opera
○ Final support by Internet Explorer 10

WebSocket background
● Goal:
○ Full-duplex bidirectional communication between a
web client and a web server
● Why not just plain TCP?
○ Mainly for security reasons (the client runs untrusted
code; origin-based security model; ports 80/443)
● Why not just HTTP for two-way messages?
○ Paradoxically, HTTP is better at sending low-latency,
high-frequency messages from the server to the
client, than vice versa
■ Full round trip always required (no pipelining)
■ No control over connection reuse
■ No control over message ordering

WebSocket protocol:
handshake
Request (from client) Response (from server)
URL: ws://push.lightstreamer.com/lightstreamer HTTP/1.1 101 Switching Protocols
("wss:" if over TLS) Upgrade: websocket
Connection: Upgrade
GET lightstreamer HTTP/1.1 Sec-WebSocket-Accept: RzdoguOqJtIsv+a+Ufu0Eq9guxU=
Host: push.lightstreamer.com Sec-WebSocket-Protocol: js.lightstreamer.com
Upgrade: websocket Sec-WebSocket-Version: 13
Connection: keep-alive, Upgrade Date: Fri, 9 Nov 2012 16:23:13 GMT
Sec-WebSocket-Key: vd0c3HNgzfWxVFCV2k5AHg== Server: Lightstreamer/5.0 build 1581 (Lightstreamer Push Server -
Sec-WebSocket-Protocol: js.lightstreamer.com www.lightstreamer.com) Vivace edition
Sec-WebSocket-Version: 13
Origin: http://www.lightstreamer.com
Other HTTP headers (Accept, Cookie, User-Agent, etc.)

● Upgrade from HTTP
● Sec-WebSocket-Key to prevent cross-protocol attacks
● Support for subprotocols
● Support for CORS (Cross-Origin Resource Sharing)

WebSocket protocol:
messages
● Full-duplex message-oriented protocol
○ After the handshake, the client and the server can
send messages asynchronously
○ The WebSocket API works at message level
(onmessage, send), while TCP is stream oriented
● Fragmentation
○ Messages are split into frames, to allow:
■ Sending messages of unknown size without buffering
■ Multiplexing more logical channels on the same connection
○ Frames sent from the client must be masked
■ Masking (XOR with random key) prevents cache poisoning on
flawed proxy servers. No masking from server to client
○ Control frames (Ping/Pong)

WebSocket vs. HTTP
Sensor example: unidirectional scenario (from server to client), so with
WebSocket the behavior is the same as with Comet streaming.
The real difference arises for bidirectional scenarios:

TCP connection 1 TCP connection 1 TCP connection 2
WebSocket

HTTP

Browser Server Browser Server Browser Server

So many buzzwords...
Real-Time WebSockets
Web Comet
Web
Push Web Push
Technology Streaming
Internet
Data Real-Time Messaging
Streaming Notifications
Ajax
Last Mile Revers Push
Messaging e Ajax etc. etc.

Lightstreamer architecture
Data Adapter

Internet
Back-end Metadata Adapter Server Client
(Web Browser,
Systems Mobile App, etc.)

Web Server

Lightstreamer Server: stand-alone process that runs in a Java virtual machine

Lightstreamer Data Adapter: custom component based on the provided API
(Java, .NET, and TCP sockets) that attaches the data feed to the Server and
injects the real-time data flow

Lightstreamer Metadata Adapter: custom component based on the provided
API that manages authentication, authorization, and entitlement logic

Rich set of Lightstreamer
client APIs
A client library is provided for each platform:
○ HTML, HTML5, JavaScript
○ Android
○ Apple iOS (iPhone, iPad, iPod)
○ Adobe Flash, Flex, AIR
○ Microsoft Silverlight
○ Microsoft .NET
○ Microsoft WinRT
○ Microsoft Windows Phone 7 and 8
○ Java SE
○ Java ME, BlackBerry
○ Generic client (open protocol)

Three logical layers of
Lightstreamer Server
Data optimization + security
○ Bandwidth and frequency allocation,
throttling, conflation, resampling, delta
3 delivery, batching
○ Custom authentication, fine-grained
authorization
Message routing
2 ○ Publish-subscribe, multiplexing, fan-out
Web transport
1 ○ Bidirectional transport layer based on Web
protocols with Stream-Sense

1. Web transport: Stream-
Sense
● Automatic and fast detection of the best transport on a
per-client basis
● Upper layers are fully abstracted from the actual transport
WebSocket

HTTP Streaming

HTTP Smart Polling

● Bidirectional channel provided in all the cases, with in-
order guaranteed message delivery and automatic
batching from client to server
See live Round-Trip Demo:
http://www.lightstreamer.com/demo/RoundTripDemo/

2. Message routing:
publish-subscribe
● Client subscribes to items with schemas (sets of fields):
Field "A" Field "A"
Field "X"

Item 1

Item 2

Item 3
subscribes Field "X"
Client Field "B"
Field "C"
Field "C" Field "Y"
Field "Y"

Sensor example: Item = "Sensor 845"
Fields = "Temp", "Hum", "Timestamp"
● Data Adapter publishes on demand:
start publish publishes Item 1 Item 1 Item 1
Item 1 Data Adapter snapshot update 1 update 2

start publish publishes Item 2 Item 2 Item 2
Item 2 Data Adapter snapshot update 1 update 2

2. Message routing:
publish-subscribe (2)
● Server sends multiplexed data to Client:
delivers Item 1 Item 1 Item 2 Item 1 Item 2 Client
snapshot update 1 snapshot update 2 update 1

● Any routing scenario is supported (broadcast, multicast,
unicast):
publishes 1 Client 1
Item 1 item Massive fan-out,
Data Adapter ...
(once) item 1 broadcast
Client 1,000,000

publishes
Item 1 item
1 Client 1 Personal messages,
Data Adapter unicast
item 2
publishes Client 2
Item 2

2. Message routing:
publish-subscribe (3)
● Asymmetric pub-sub:
Data Adapter Client
Publisher Subscriber

○ In many scenarios the "data feed" is completely different from the data
consumer (topology, protocol, business model)
○ Optimization for massive publishing from server-side data feeds
● Clients can still publish:
Data Adapter Client
Publisher Subscriber
sendMessage
○ The Client (Subscriber API) can send messages to the Adapter to be
processed and possibly incorporated into the data stream

3. Data optimization:
filterability
● Data filterability:
○ Based on the nature of the data, series of updates to
an item can be filtered, to reduce frequency, via:
■ Queueing
■ Resampling
■ Conflation
● Lightstreamer's filtering
○ 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

dynamic throttling
● Bandwidth allocation:
○ For each client, a maximum bandwidth can be
allocated to the multiplexed stream connection
● Frequency allocation:
○ For each subscription of each client, a maximum
update frequency can be allocated
● Real bandwidth detection:
○ Internet congestions are detected
Lightstreamer heuristically combines these
three categories to dynamically throttle the data
flow with filtering See live Bandwidth and Frequency Demo:
http://www.lightstreamer.com/demo/BandwidthDemo/

other mechanisms
● Batching and TCP packet optimization:
○ Data is aggregated efficiently within TCP packet
○ Configurable trade-off between latency and
overhead reduction, overriding Nagle's algorithm
● Lightweight protocol:
○ Position-based protocol with negligible overhead (no
JSON, no XML, no metadata redundancy)
● Delta delivery:
○ For subsequent updates to an item, only the actually
changed fields (delta) are sent
● Multiple subscription modes:
○ Merge, Command, ... See live Portfolio Demo:
http://www.lightstreamer.com/demo/PortfolioDemo/

Scalability
● Concurrent staged event-driven architecture
○ Non-blocking I/O used for all types of connections
○ Graceful degradation of the quality of service
○ Tested on a single box with:
■ one million connections with low frequency traffic
■ tens of thousands connections with very high
frequency traffic
● Vertical scalability
○ An instance of Lightstreamer Server can fully
leverage multiple CPUs and cores available in a box
● Horizontal scalability
○ Clustering via any standard Web Load Balancer

Lightstreamer editions
● Lightstreamer Moderato (free)
○ No bandwidth allocation, TLS support, clustering
○ Only JavaScript client library
○ Max 1 update/s per item
● Lightstreamer Allegro
○ As Moderato, but with clustering
● Lightstreamer Presto
○ All client libraries and bandwidth allocation
○ Max 3 update/s per item
● Lightstreamer Vivace
○ Unlimited update/s per item
○ JMX management API

Lightstreamer links
Dow
Website n
www load
www.lightstreamer.co .light
m strea
mer.co
Forums m/do
wnlo
forums.lig ad
htstreame
Blog r.com
mer.com
blog.lightstrea
Twitter
10263
11364940 @lightstr
93343 eam
G oogle+ oogle.com/108 er
s.g
http://plu
Facebook om/Lightstre
amer
ok.c
LinkedIn www.facebo
http://www.linkedin.com/e/vgh/2218807

Careers
GitHub careers@lightstream
https://github.com/Weswit er.com

CommTech Talks: Lightstreamer (A. Alinone)

More Related Content

Similar to CommTech Talks: Lightstreamer (A. Alinone) (20)

More from Antonio Capone (14)

CommTech Talks: Lightstreamer (A. Alinone)