What’s RSocket?

RSocket is a binary, asynchronous, one-to-one, stateless, symmetrical protocol that relies on one between TCP, WebSocket, Aeron, and HTTP/2 streams to be used as a transport protocol behind the curtains.

It’s been developed to match the Reactive Streams semantics, therefore integrating seamlessly in applications that depend heavily on Reactive libraries such as Project Reactor or ReactiveX.

Why should I use RSocket?

Bare HTTP just doesn’t cut it, especially in the modern world where software architecture leans heavily towards microservices.

Microservices need to communicate potentially with a myriad of other microservices, in a tangled and twisted dance that doesn’t always go along with the core principles upon which HTTP has been built: sending text over the wire, in a request ⇄ response fashion.

It is often required that microservices send out events in a fire-and-forget manner (brokers and advanced messaging protocols help with this, but at the cost of adding significant complexity to infrastructure and applications relying on them), or request some data and hold onto the connection expecting a stream of data coming through as a response, over time.

HTTP is not an efficient solution in either of these scenarios, whereas a transport protocol that’s been built specifically for computers talking to other computers asynchronously and with high-performance in mind, such as WebSocket, seems to be a very good fit.

RSocket provides all the advantages of choosing the best transport protocol for the task, and builds things like Reactive Streams semantics, backpressure management, load-balancing hints and resumability on top of it! Great stuff!

Interaction models

RSocket is based on 4 main interaction models that enable symmetric interaction over a single connection:

request/response : similar to HTTP, but the client waits for the response (stream of 1 element) in a non-blocking manner;

: similar to HTTP, but the client waits for the response (stream of 1 element) in a non-blocking manner; request/stream : the client receives elements that compose a stream of many, over time;

: the client receives elements that compose a stream of many, over time; fire-and-forget : the client sends some data and expects no response;

: the client sends some data and expects no response; channel: the most customizable interaction model, where the client and the server can exchange data in any way that seems fit for a specific task (eg. server sends 2 frames for each frame* sent by the client).

*a frame is a single message containing either a request or a response

Resilience and High Availability

RSocket satisfies resiliency and high availability requirements by providing features such as connection/request resumption and load-balancing hints through leasing.

Resumption is the ability to resume an operation in case of failure (eg. recovering an abruptly closed connection).

When using RSocket, clients are completely in charge of resumption, and it is not enabled by default.

It is particularly useful as, when sending a RESUME frame containing information about the last received frame, the client is able to resume the connection and only request the data it hasn’t already received, avoiding unnecessary load on the server and wasting time trying to retrieve data that was already retrieved.

It should be used everywhere, where it makes sense to do so.