The document summarizes a virtual meetup of the MuleSoft Meetup Group in Pune, India that took place on April 18th, 2020. The meetup agenda included a presentation on using the Mule 4 WebSocket Connector for real-time integration with clients using the WebSocket protocol. The presentation covered WebSocket concepts, use cases, the connector's configuration and operations, and examples demonstrating how to use the connector to establish bidirectional communication between a server and client. Best practices for using the WebSocket protocol were also discussed.

1. [18th April 2020]: [MuleSoft Meetup Group]
Meetup #21 (VIRTUAL)
[PUNE-India]

2. All contents © MuleSoft Inc. 2
Santosh
Ojha
Seemant
Jain
Mukesh Thakur
Satya Sekhar
Presenters, Organizers and You
Who is new to this Meetup?
Manish Yadav

3. All contents © MuleSoft Inc.
Agenda
3
• Introduction
• Mule 4 - Real Time Integration with Server and Client using Web
Sockets Connector
– Introduction to Full Duplex Communication
– About WebSocket Protocol
– Few Use Cases where WebSockets can be used
– Connector Configurations & Operations
– Examples & Demos
– Best Practices
• What’s next

4. All contents © MuleSoft Inc.
Goal
4
• Understand the WebSocket Protocols and basic Concepts
• Use Cases of WebSocket
• Learn the Mule 4 WebSocket Connectors and it’s Configuration
• Understand the operations of WebSocket Connectors
• When to use and when not to use WebSocket

5. All contents © MuleSoft Inc.
What is WebSocket Protocol
5

6. All contents © MuleSoft Inc.
Half Duplex Communication
6
In traditional HTTP, a connection is half-duplex (unidirectional) and works by
using a request-response message exchange pattern:
• A client connects to a server and sends a request.
• The server processes the request and sends a response back. The connection
ends after the client receives the request.

7. All contents © MuleSoft Inc.
Traditional way of Bi-Directional (Full Duplex)
Communication
7
A web applications that needs bidirectional communication between a client and
a server (e.g., instant messaging and gaming applications) has required to HTTP
poll the server for updates.
This results in a variety of problems:
• The server is forced to use a number of different underlying TCP connections
for each client: one for sending information to the client and a new one for
each incoming message.
• The wire protocol has a high overhead, with each client-to-server message
having an HTTP header.
• The client-side script is forced to maintain a mapping from the outgoing
connections to the incoming connection to track replies.

8. All contents © MuleSoft Inc.
A Simpler Solution
8
• Use a single TCP connection for traffic in both directions.
• WebSocket protocols provides an alternative to HTTP polling for two-way communication from
a web page to a remote server.
• Relationship to TCP and HTTP
• The WebSocket Protocol is an independent TCP-based protocol.
• Its only relationship to HTTP is that its handshake is interpreted by HTTP servers as an
Upgrade request.
• By default, the WebSocket Protocol uses port 80 for regular WebSocket connections
• For Transport Layer Security (TLS) it uses port 443

9. All contents © MuleSoft Inc.
What is WebSocket Protocol
9
• The WebSocket Protocol enables two-way communication between a client
running untrusted code in a controlled environment to a remote host that has
opted-in to communications from that code.
• A WebSocket is built on top of the existing HTTP infrastructure, making it
easy to reuse infrastructure that is already in place for traditional HTTP.
• The security model used for this is the origin-based security model commonly
used by web browsers.
• The protocol consists of an opening handshake followed by basic message
framing, layered over TCP. The goal of this technology is to provide a
mechanism for browser-based applications that need two-way communication
with servers that does not rely on opening multiple HTTP connections

10. All contents © MuleSoft Inc.
Use Cases of WebSocket Applications
10
• Social Feeds
• Stock Market Applications
• Currency exchange rates / Financial Ticklers
• https://pro.coinbase.com/trade/BTC-USDC
• Instant messaging / Chat
• Multi Player Gaming applications
• Collaborative Editing/Coding
• Sports Updates
• Location Based Apps
• Online Educations

11. All contents © MuleSoft Inc.
Anatomy of WebSocket Protocol
11
The protocol has two parts: a handshake and the data transfer.
• The handshake from the client looks as follows:
GET /chat HTTP/1.1
Host: server.example.com
Upgrade: websocket
Connection: Upgrade Sec-WebSocket-Key: dGhlIHNhbXBsZSBub25jZQ==
Origin: http://example.com
Sec-WebSocket-Protocol: chat, superchat
Sec-WebSocket-Version: 13
• The handshake from the server looks as follows:
HTTP/1.1 101 Switching Protocols
Upgrade: websocket
Connection: Upgrade
Sec-WebSocket-Accept: s3pPLMBiTxaQ9kYGzzhZRbK+xOo= Sec-WebSocket-Protocol: chat
• Major Steps:
• Opening a handshake
• Data Framing
• Sending and Receiving Data
• Closing the Connection

12. All contents © MuleSoft Inc.
WebSocket URI
12
WebSocket URIs
• ws-URI = "ws:" "//" host [ ":" port ] path [ "?" query ]
• wss-URI = "wss:" "//" host [ ":" port ] path [ "?" query ]
• The port component is OPTIONAL; the default for "ws" is port 80, while the
default for "wss" is port 443.

13. All contents © MuleSoft Inc.
Opening a handshake
13
The opening handshake is intended to be compatible with HTTP-based server-
side software and intermediaries, so that a single port can be used by both HTTP
clients talking to that server and WebSocket clients talking to that server.
To this end, the WebSocket client's handshake is an HTTP Upgrade request:
GET /chat HTTP/1.1
Host: server.example.com
Upgrade: websocket Connection:
Upgrade Sec-WebSocket-Key: dGhlIHNhbXBsZSBub25jZQ==
Origin: http://example.com
Sec-WebSocket-Protocol: chat, superchat
Sec-WebSocket-Version: 13

14. All contents © MuleSoft Inc.
What is Data Framing?
14
• In the WebSocket Protocol, data is transmitted using a sequence of frames.
• A client MUST mask all frames that it sends to the server
• The server MUST close the connection upon receiving a frame that is not
masked.
• A server MUST NOT mask any frames that it sends to the client.
• A client MUST close a connection if it detects a masked frame.
• A data frame MAY be transmitted by either the client or the server at any time
after opening handshake completion and before that endpoint has sent a
Close frame

15. All contents © MuleSoft Inc.
Sending Data
Sending and Receiving Data
15
• The endpoint MUST ensure the WebSocket connection is in the OPEN state
• If at any point the state of the WebSocket connection changes, the endpoint MUST abort the
following steps:
• If the data to be sent is large or if the data is not available in its entirety at the point the
endpoint wishes to begin sending the data, the endpoint MAY alternately encapsulate the
data in a series of frames
• The opcode (frame-opcode) of the first frame containing the data MUST be set to the
appropriate value for data that is to be interpreted by the recipient as text or binary data.
• The FIN bit (frame-fin) of the last frame containing the data MUST be set to 1
• If the data is being sent by the client, the frame(s) MUST be masked
• The frame(s) that have been formed MUST be transmitted over the underlying network
connection.

16. All contents © MuleSoft Inc.
Receiving Data
Sending and Receiving Data
16
• To receive WebSocket data, an endpoint listens on the underlying network
connection.
• Incoming data MUST be parsed as WebSocket frames

17. All contents © MuleSoft Inc.
Connection Closing
17
• An endpoint SHOULD use a method that cleanly closes the TCP connection, as well
as the TLS session, if applicable, discarding any trailing bytes that may have been
received.
• The underlying TCP connection, in most normal cases, SHOULD be closed first by
the server, so that it holds the TIME_WAIT state and not the client
• In abnormal cases (such as not having received a TCP Close from the server after a
reasonable amount of time) a client MAY initiate the TCP Close.
• when a server is instructed to _Close the WebSocket Connection_ it SHOULD
initiate a TCP Close immediately
• When a client is instructed to do the same, it SHOULD wait for a TCP Close from
the server.

18. All contents © MuleSoft Inc.
About the WebSocket Connector
18
MuleSoft released the WebSocket connector for Mule 4 recently. This connector
has below integration capabilities :
• Establishes bidirectional and full-duplex communication between a server and client
• Implements server push notifications
• Seamlessly works on top of an existing HTTP infrastructure
• Avoids the need for clients to regularly poll the server for new data
• Compatibility:
Mule 4.2.2 or higher
Java 1.8.0_x
Anypoint Studio 7.4 or higher

19. All contents © MuleSoft Inc.
Start with the WebSocket Connector
19
• Socket Types
• Inbound - Created when the Mule app listens for incoming connections. An external
system connects to an endpoint exposed by the Mule app.
• Outbound - Created when the Mule app connects to an external system. Mule app
initiates communication and asks an external system to establish a WebSocket.
• Socket ID: Both inbound and outbound, have a unique socket ID that identifies them. The app
must reference these IDs to operate on individual WebSockets.
• Groups: This is useful for message segregation, which enables the app to broadcast a single
message to a group of different WebSockets clients. An app can use groups to broadcast one
single message to a group of different WebSockets. Groups facilitate the process of identifying
which WebSockets should participate in each broadcast. WebSockets clients can optionally
subscribe to Group

20. All contents © MuleSoft Inc.
Start with the WebSocket Connector
20
• Triggers: Triggers initiate the execution of a flow upon receiving a message or
event notification:
– inbound-listener: exposes an endpoint that external systems can connect to and initiates
the containing flow when a message is received.
– on-inbound-connection: initiates a flow when a new connection to the Inbound Listener
is established.
– outbound-listener: exposes an endpoint that initiates a flow when outbound WebSockets
receive a message from an external system.
– on_connection-closed: initiates the containing flow when inbound or outbound
WebSockets close.

21. All contents © MuleSoft Inc.
Start with the WebSocket Connector
21
• Operations:
• open-outbound-socket: connects to an external system and creates
an outbound webSocket.
• Send: sends a message through a WebSocket.
• subscribe-groups: subscribes a WebSocket to one or more groups.
The app can invoke this operation on the same WebSocket multiple times.
each invocation being additive over the previous ones. Repeated groups are
ignored.
• unsubscribe-groups: unsubscribes a WebSocket from one or more
groups.
You can invoke this operation multiple times on the same socket, with each
invocation being additive over the previous ones. Repeated groups are ignored.
• broadcast sends a message to multiple WebSockets classified by path,
type, and group.
• close-socket closes a WebSocket’s connection.

22. All contents © MuleSoft Inc.
Installing the WebSocket Connector
22
• WebConnector doesn’t ship by default with Anypoint Studio
• You need to download / install it from exchange: Refer:
https://docs.mulesoft.com/connectors/websockets/websockets-connector-studio
• Pom Dependency :
– <dependency>
<groupId>com.mulesoft.connectors</groupId>
<artifactId>mule-websockets-connector</artifactId>
<version>RELEASE</version>
<classifier>mule-plugin</classifier>
</dependency>

23. All contents © MuleSoft Inc.
Demo & Examples
23
• Note: Before creating an app, you must have access to the WebSockets target resource and
Anypoint Platform. You must also understand how to create a Mule app using Anypoint Studio.
• Example 1:
– Java based Socket Server
– Mule based Client
• Example 2:
– Mule based Client & Server

24. All contents © MuleSoft Inc.
When not to use WebScoket
Best Practices
24
• Retrieve Resource
• Highly Cacheable Resource
• Idempotency and Safety
• Error Scenarios
• Synchronized Events
• Don’t use a WebSocket for anything other than realtime two-way communication.
• If you are expacting to receive response with the extra interval or huge amount of
time before receiving response from server to client, do not use the WebSocket
because it will consume the resources of your server cpu/ memory to process the
message from server to client

25. All contents © MuleSoft Inc.
Best Practices
25
• Always implement the Secure connection between server and client for secure
communication
• Implement the close connection, when purpose is fulfilled to close the connection.
• Before designing/ recommending the WebSocket understand the use cases.
• If deploying to CloudHub:
– If your app has inbound WebSockets endpoints only, to deploy the app in CloudHub you
must:
– Configure an Anypoint Virtual Private Cloud (VPC).
– Set up a dedicated load balancer to route WS and WSS traffic through the Mule app.

26. All contents © MuleSoft Inc.
Best Practices
26
– To set up the inbound WebSocket endpoints:
• Configure the WebSockets inbound listener (<ws:inbound-listener>) to listen on one of the
following ports:
• 0.0.0.0.
– To communicate over WS, set the listener port to 8091.
– To communicate over WSS, set the listener port to 8092.
• Deploy your app to the VPC.
• Set up the dedicated load balancer’s URL mapping rules to associate a URI to a
specific app.
Github url :- https://github.com/expertsekhar/websocket

27. Open forum discussion
( Q&A, Topics for next meetup )

28. All contents © MuleSoft Inc.
What’s next
28
• Share:
– Invite your network to join: https://meetups.mulesoft.com/Pune/
• Feedback:
– Contact your organizer to suggest topics
– Contact MuleSoft at meetup@mulesoft.com for ways to improve the program
– Your Feedback is catalyst for us
• Our next meetup:
– Date: TBD
– Location: PUNE
– Topic: TBD

29. All contents © MuleSoft Inc.
Take a stand !
29
• Nominate yourself for
the next meetup speaker
and suggest a topic as
well.

30. See you next time
Please send topic suggestions to the organizer

31. Thank You