RSocket is an asynchronous network communication protocol where communication is modelled as multiplexed streams of messages over a single network connection. In a presentation at QCon London 2019, Robert Roeser explained the reasons for creating RSocket and the communication model used. In the same presentation, Ondrej Lehecka described two use cases, and Andy Shi ran a demo using the benefits of RSocket.
Roeser, CEO at Netifi, formerly at Netflix, started by describing how during his time at Netflix, they decided to build a protocol that would make it easier to build distributed systems. They wanted to create a standard way for applications to communicate with each other across a network, and in a consistent way. He notes that this not only includes microservices, but also other devices that may be involved.
Looking at what RSocket can provide when building distributed systems, Roeser notes three things:
- A communication model across the network
- A method to transmit data between nodes — a network protocol
- Flow control between the nodes
The RSocket communication model uses a message-based binary protocol. It uses the concept of a requester and a responder that interacts with each other by sending binary frames as messages. They picked a binary format instead of a human readable format because from tests they found the binary format to be up to 30% faster. This decreases latency and for Roeser this is significant in a distributed system, since it affects all calls down the graph of services. RSocket is also payload agnostic to support all the different use cases.
RSocket is multiplexed and connection oriented. Roeser points out that it’s very inefficient when a protocol requires that you create a new request each time. Instead, he wants each client to create one connection into the infrastructure and then send multiple requests through virtual streams. This creates a multiplexing issue which is solved by annotating each message with a stream id, making it is possible to partition the connection into logical streams. He claims that this allows for a more efficient use of connections, and a need for less servers due to the lower number of connections used.
At the network level, RSocket provides different interaction models:
- Request – Response, which is a stream of one; you send one message and get one back
- Fire and forget, where you send one frame but nothing is returned. Roeser points out that it’s not about ignoring a response; nothing is returned which is more efficient
- Request-stream. Here you send one request and get a stream of responses back
- Channel or a bidirectional stream, where you send a stream of requests and get a stream of responses back
A feature Roeser thinks is quite unique for RSocket is that it is bi-directional. After a client has initiated a connection to a server, there is no difference between the client and the server. They are equal members which means that both can send data to the other. This enables for example a web browser to connect to a service which then can call an API in Java-script in the browser. RSocket also includes a message-based flow control, but instead of the common technique of acting on number of bytes, RSocket acts on the number of messages per second flowing through the system.
RSocket abstracts away the underlying transport with the only requirement on the transport layer that it’s bi-directional. Roeser notes that this makes it possible to write an application once using the RSocket API, and then use different transports without any change in the business logic. Current implementations include HTTP/2, TCP, WebSocket and shared memory.
After Roeser’s introduction to RSocket, Lehecka, software engineer at Facebook, described two use cases. The first was around using live queries. Facebook uses GraphQL to retrieve data that needs to be updated regularly on the client. Typically, this has been done by regular queries from the client. Using RSocket, the client can instead use a get-and-subscribe request and automatically get live updates as they happen.
Lehecka’s second use case was about client monitoring. A huge number of clients connect to Facebook and all of them are collecting their own logs with telemetry, counters, etc. All these logs have to been collected server-side for needs such as monitoring and the ability to debug client issues. Using RSocket, this can be enhanced by allowing the server to send a request to individual clients and have them start streaming detailed logs back to the server.
In a similar use case, Andy Shi of Alibaba ran a demo showing how log files can be streamed from a single client to a consumer, without any need of a database or buffers.
The slides from the presentation are available for download. Most presentations at the conference were recorded and will be available on InfoQ over the coming months. The next QCon conference, QCon.ai, will focus on AI and machine learning and is scheduled for April 15 - 17, 2019, in San Francisco. QCon London 2020 is scheduled for March 2 - 6, 2020.