1st Session - WebSockets, a Server Push Technology: - Differences between Pull and Push technologies - What are WebSockets - A bit of History behind WebSockets - When to use WebSockets - How to integrate WebSockets with OutSystems - Considerations when using WebSockets Free Online training: https://www.outsystems.com/learn/courses/ Follow us on Twitter http://www.twitter.com/OutSystemsDev Like us on Facebook http://www.Facebook.com/OutSystemsDev

1. Enterprise Application
Performance
Server Push Technologies - WebSockets
Solution Architect - Experts Team
Tito Moreira

2. Performance Hurdles
• Application code
○ Too many accesses to database
○ Poor client-side programming (Client-side polling, JS, CSS, HTML)
• Infrastructure
○ Database
○ Network

3. Long polling (pull)
Pull - Long Polling using Web requests
Since HTTP is stateless,
the Session and other data
might need to be read from
the database

4. Pull vs Push technologies
Information about
the connection
(IP, port and
identifier of the
recipient) is stored
in memory
(stateful)

5. WebSockets
A brief History of WebSockets...
1973
TCP/IP
design
1969
ARPANET
1989
WWW, HTML,
HTTP created
by CERN to
reference
documents in
the Internet
2009
1st draft of
WebSocket
protocol
(hixie)
2010
Chrome,
Safari,
Firefox,
Opera adds
support for
WebSockets
2011 Dec
WebSocket
protocol gets
Internet
Standard
classification.
RFC
published
1997
HTTP/1.1
RFC
published
2015
HTTP/2.0
RFC
published
(TCP
connection
reuse)
Time

6. WebSocket (RFC 6455) Browser support

7. WebSockets
• WebSocket is a protocol
○ Allows two-way communication between a client and a server
over TCP/IP
○ The goal of WebSockets is to provide a mechanism to browser
applications that need two-way communication with servers to
avoid opening multiple HTTP connections or using long
polling (AJAX, iframes, etc)

8. HTTP requests vs WebSockets
Client Server Client Server
Bi-directional messages
Connection Lifecycle
(TCP/IP)
HTTP/REST requests WebSockets
For requests
not sent in the
same TCP
connection
ping! (0x09)
pong!
(0xA)
close
(0x8)

9. WebSocket vs standard HTTP requests
Source: http://blog.arungupta.me/rest-vs-websocket-comparison-benchmarks/
• Constant payload 1KB, increasing number of messages

10. WebSocket vs standard HTTP requests
Source: http://blog.arungupta.me/rest-vs-websocket-comparison-benchmarks/
• Performance with ≠ payload size for constant number of messages (1000)

11. WebSockets
• WebSocket handshake is initiated from an HTTP request
• Sub-protocols can be negotiated

12. When to use Server Push technologies
(WebSockets) ?

13. Recommended uses for WebSockets
• To implement Functional Requirements
○ When Web Apps need server data that is constantly changing
■ High volatile data change events (Tickers, Price updates, Real Time data, etc)
■ Results from background processing tasks
■ User notifications
■ Communication between Users (collaborative scenarios)
○ Present “small” bits of information to Users as soon it is available
■ Auction prices, Sports updates, tickers, location based data, etc

14. Recommended uses for WebSockets
• To address Architectural restrictions
○ To get around the infamous 6 connections per host limit.
○ To allow Browsers to access local resources (native)
■ Browser ActiveX/Java plugin migrations
■ Installation of a local service (with a WebSocket server) for providing Biometric
authorization or other events

15. How to integrate WebSockets
with OutSystems?

16. For Cloud based WebSocket services
• Pick a WebSocket Cloud service that exposes a server-side API.
■ The Server-side API allows OutSystems Apps to push data
• Usually provide authorization (token based) and transport
security (TLS/SSL)
■ Secure WebSockets (WSS)
• Choose a Cloud Service that implements fallback mechanisms
■ The Client-side script should have fallback to older (more
mainstream) technologies
• Pick the Cloud service that has the lower latency
■ For your target Users
■ For the OS Infrastructure

17. Integration with OutSystems
Cloud Pusher.com service (example)
Client
(Browser)
Standard
AJAX or
Page view
request
(HTTP 1.1)
Front End
Load Balancer
OutSystems FrontEnd
Servers
WebSocket
Server
(pusher.com)
Pusher.com uses
WS/WSS protocol
To push data
to clients
Client
(Browser)
By using Pusher server-side REST
API, a background process can
publish data to a Client or group of
Clients
Pusher client script
Client
(Browser)
Pusher client script
Client
(Browser)
Pusher client script
HTTP Web request
WebSocket protocol
REST API request
Source: http://www.asp.net/signalr/overview/performance/scaleout-in-signalr

18. Known WebSocket Cloud services
• Pusher
• PubNub
• Fanout (also works as Reverse Proxy)
• Google App Engine with Channel API
• Hydna
• Firebase + Fire# (server-side C# API)
• Azure Web Apps support WebSockets
...

19. For self-hosted WebSocket server
• The WebSocket cluster should be in a dedicated infrastructure
○ Don’t install WebSockets server software in the OS FrontEnd Servers
○ It has different resource needs (scales differently than OS FEs)
○ The WebSocket server maintenance and support tasks won’t affect OS
servers and vice-versa
○ Can be migrated to another environment (3rd Party Cloud services)
• Use a WebSocket server that exposes a REST service
○ OS apps will call this service to push data to browser clients
• Implement authorization (tokens or API keys)
○ WebSocket servers that are exposed to the public, should check for an
API Key or Token that is sent by the Client to verify authorized access.

20. Integration with OutSystems
Self-hosted HA SignalR (example)
Client
(Browser)
A background process can call an
ASP.NET Web API REST service
to publish data to a Client or
group of Clients
Standard AJAX or Page
view requests (HTTP 1.1)WS/WSS protocol
ASP.NET SignalR 2.0
WebSocket Servers
SQL Server Backplane
Load Balancer
Source: http://www.asp.net/signalr/overview/performance/scaleout-in-signalr
OutSystems FrontEnd
Servers
Client
(Browser)
SignalR client script
Client
(Browser)
SignalR client script
HTTP Web request
WebSocket protocol
REST API request
SQL Query

21. Known self-hosted WebSocket servers
• NodeJS
○ Socket.io, sockJS, FAYE, etc
• ASP.NET SignalR (>= Windows 2012 R2)
• IISNode (Yes! Node inside IIS on a ≠ App pool)
• Jetty (Java)
• websocketd (Linux only)
• SuperSocket (library for custom server in C#)
...

22. WebSockets considerations
• Compatibility problems with HTTP proxies
○ The WebSocket HTTP Upgrade (normally used for HTTP/SSL) request can be dropped by some (old)
Proxies, making it impossible to establish a connection.
• Security (to prevent man-in-the-middle) for WebSockets
○ Use TLS/SSL for the Web Applications. Most WebSocket frameworks will use the wss:// (TLS/SSL) for the
WebSocket connection too.
• DoS
○ Most Browsers impose a limit between 200-3000 WebSockets. A malicious Site can exhaust the max
connections of the Browser. It’s also possible for a client to DoS a server.
• Authorization/Authentication
○ The WebSocket protocol doesn’t handle authorization or authentication.
○ WebSocket opened from a page with auth doesn’t “automatically” receive any sort of auth

23. WebSockets considerations (cont.)
• Some WebSocket servers don’t allow cross site connections
although they can be configured (CORS)
○ SignalR (by default) checks Origin header to verify if the Script origin is the same
• Check that you are effectively using WebSockets instead of a
Pull fallback mechanism
○ Most frameworks will fallback quietly to Long Polling if the Browser or Server (SignalR)
don’t support the WebSocket protocol
○ Use Developer Browser tools to check if
WS protocol is effectively used
• Standard not implemented the same
way or not supported by all browsers
○ That’s why using an abstraction client framework (with fallback mechanism) is a good idea!

24. WebSockets in Action!
(demo)

25. We’ll be back in 5 min to answer
your questions

26. Thank you!