commtech talks: lightstreamer (a. alinone)
DESCRIPTION
TRANSCRIPT
Alessandro AlinoneCo-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
Lightstreamer:some customers
Some more customers...
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 WebInformation 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
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 illustrateA temperature and humidity sensor must send data to a Web browser (sensor example).
Let's see how this might have been done in the history of push technology.
Web
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 Comet2005: Ajax (Asynchronous JavaScript and XML)
Jesse JamesGarrett
2006: Comet
AlexRussell
HTTP/1.1 - Hypertext Transfer Protocol
RequestGET / HTTP/1.1Host: www.facebook.comUser-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:16.0) Gecko/20100101 Firefox/16.0Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8Accept-Language: en-US,en;q=0.5Accept-Encoding: gzip, deflateConnection: keep-aliveCookie: datr=IeCPUJWOBWaU0LrmpOTOC-YX; reg_fb_gate=http%3A%2F%2Fwww.facebook.com%2F; reg_fb_ref=http%3A%2F%2Fwww.facebook.com%2F; wd=1080x1281Cache-Control: max-age=0
ResponseHTTP/1.1 200 OKCache-Control: private, no-cache, no-store, must-revalidateExpires: Sat, 01 Jan 2000 00:00:00 GMTP3P: CP="Facebook does not have a P3P policy. Learn why here: http://fb.me/p3p"Pragma: no-cacheX-Content-Type-Options: nosniffX-Frame-Options: DENYX-XSS-Protection: 1; mode=blockSet-Cookie: reg_ext_ref=deleted; expires=Thu, 01-Jan-1970 00:00:01 GMT; path=/; domain=.facebook.comSet-Cookie: wd=deleted; expires=Thu, 01-Jan-1970 00:00:01 GMT; path=/; domain=.facebook.com; httponlyContent-Encoding: gzipContent-Type: text/html; charset=utf-8X-FB-Debug: 4wzuaiMEh5R1tzwT7CBNVncjMl1zLu3fmz4CvMLu+UQ=Date: Tue, 30 Oct 2012 14:16:12 GMTTransfer-Encoding: chunkedConnection: keep-alive
2d2e
...........}[o#Y..{..lNO..-..[...u.J...R.&.L&........j....0.'...a.afoX.^`.{...3.`.{.....?._..L&/.....w.]...d.s.....'"...7.6N..[R...k_..?..COMPRESSED CONTENT..........................................
Request
Response
Full page refreshTypical issues:● Low update frequency; no
real time● High bandwidth usage● High load on Web server
Sensor example: for each refresh, the full HTML page with the current values is retrievedwait...
wait...
wait...
Refresh 1
Browser Server
wait...
Refresh 2
User
wait...
Refresh 3
wait...
Ajax pollingTypical issues:● Low update frequency; no
real time● High bandwidth usage (but
lower than page refresh)● High load on Web serverAdvantages:● User interface is never
blockedSensor example: for each poll, the current values are retrieved
wait...
wait...Action 1
Browser Server
Action 2
User
wait...
Comet long pollingTypical issues:● Medium update frequency;
near real time● Medium bandwidth usage
(HTTP headers still present in each round-trip cycle)
● High load on Web serverAdvantages:● User interface is never
blocked● Low latency on low-
frequency events
Action 1
Server
Action 2
User
wait...
wait...
wait...
Browser
Comet long polling (2)Sensor example: for each poll, the new values are retrieved only when they become available. Otherwise, the request is kept pending (long poll)
Action 1
Server
Action 2
User
wait...
wait...
wait...
Browser
Comet streamingTypical issues:● 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)● Low load on the network
infrastructure
Action 1
Server
Action 2
User Browser
Comet streaming (2)
Action 1
Server
Action 2
User Browser
Possible techniques:● Iframe streaming● XHR streaming● Flash streaming● Server-Sent Events
Sensor example: the server keeps pushing real-time updates as they become available, whatever is the frequency, without request/response round trips from the client
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: handshakeRequest (from client)URL: ws://push.lightstreamer.com/lightstreamer("wss:" if over TLS)GET lightstreamer HTTP/1.1Host: push.lightstreamer.comUpgrade: websocketConnection: keep-alive, UpgradeSec-WebSocket-Key: vd0c3HNgzfWxVFCV2k5AHg==Sec-WebSocket-Protocol: js.lightstreamer.comSec-WebSocket-Version: 13Origin: http://www.lightstreamer.comOther HTTP headers (Accept, Cookie, User-Agent, etc.)
Response (from server)HTTP/1.1 101 Switching ProtocolsUpgrade: websocketConnection: UpgradeSec-WebSocket-Accept: RzdoguOqJtIsv+a+Ufu0Eq9guxU=Sec-WebSocket-Protocol: js.lightstreamer.comSec-WebSocket-Version: 13Date: Fri, 9 Nov 2012 16:23:13 GMTServer: Lightstreamer/5.0 build 1581 (Lightstreamer Push Server - www.lightstreamer.com) Vivace edition
● 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
ServerBrowser
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:
ServerBrowser ServerBrowser
TCP connection 1 TCP connection 1 TCP connection 2
Web
Sock
et
HTT
P
So many buzzwords...
Comet
Push Technology
Web Streaming
Real-Time Web
WebSockets
Web Push
Data Streaming
Reverse Ajax
Last Mile Messaging
Internet Messaging
Ajax Push
Real-Time Notifications
etc. etc.
Lightstreamer architecture
Server
Data Adapter
Metadata Adapter
Web Server
Back-end Systems
InternetClient
(Web Browser, Mobile App, etc.)
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 APIsA 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 delivery, batching
○ Custom authentication, fine-grained authorization
Message routing○ Publish-subscribe, multiplexing, fan-out
Web transport○ Bidirectional transport layer based on Web
protocols with Stream-Sense1
2
3
● Automatic and fast detection of the best transport on a per-client basis
● Upper layers are fully abstracted from the actual transport
● Bidirectional channel provided in all the cases, with in-order guaranteed message delivery and automatic batching from client to server
1. Web transport: Stream-Sense
WebSocket
HTTP Streaming
HTTP Smart Polling
See live Round-Trip Demo:http://www.lightstreamer.com/demo/RoundTripDemo/
publishes
● Client subscribes to items with schemas (sets of fields):
Sensor example: Item = "Sensor 845"Fields = "Temp", "Hum", "Timestamp"
● Data Adapter publishes on demand:
2. Message routing: publish-subscribe
Client subscribesField "A"
Item
1Field "B"Field "C"
Field "X"
Item
2
Field "Y"
Field "A"
Item
3 Field "X"Field "C"Field "Y"
Data Adapterstart publishItem 1
Item 1snapshot
Item 1update 1
Item 1update 2
publishesData Adapterstart publishItem 2
Item 2snapshot
Item 2update 1
Item 2update 2
publishesItem 1
2. Message routing: publish-subscribe (2)
Clientdelivers Item 1snapshot
Item 1update 1
Item 2snapshot
Item 1update 2
Item 2update 1
● Server sends multiplexed data to Client:
● Any routing scenario is supported (broadcast, multicast, unicast):
publishesItem 1(once)Data Adapter
Client 1,000,000
Client 1... Massive fan-out,
broadcast
Data AdapterClient 2
Client 1
publishesItem 2
item 1
item 1
item 1
item 2
Personal messages, unicast
2. Message routing: publish-subscribe (3)
Data Adapter Client
Publisher Subscriber
● Asymmetric pub-sub:
○ 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:
○ The Client (Subscriber API) can send messages to the Adapter to be processed and possibly incorporated into the data stream
Data Adapter Client
Publisher Subscriber
sendMessage
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
3. Data optimization: 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 detectedLightstreamer 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/
3. Data optimization: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
Forumsforums.lightstreamer.com
Lightstreamer linksDownloadwww.lightstreamer.com/download
Websitewww.lightstreamer.com
Blogblog.lightstreamer.com
Twitter@lightstreamer
Facebookwww.facebook.com/Lightstreamer
Google+http://plus.google.com/108933431136494010263
LinkedInhttp://www.linkedin.com/e/vgh/2218807
GitHubhttps://github.com/Weswit