RSocket Can Make Service Communication More Responsive

RSocket Can Make Service Communication More Responsive

Piotr Kubowicz - March 24, 2020

RSocket is a new reactive network protocol supported by the Linux Foundation and maintainers of Spring Framework. It claims to be designed specially to address shortcomings of HTTP as a mean of connecting applications. Let’s see areas where you can expect improvement and what kind of systems will significantly benefit from using RSocket.

This article will cover:

  • visualisations showing why streaming-based communication is important
  • using Server-Sent Events for communication between microservices
  • differences in the handling of request cancellation
  • a short overview of RSocket protocol itself
  • the impact of introducing RSocket or SSE to a typical application based on Spring Framework

Reactive Stack Is Not Inherently Faster

You may be tempted to think that if you rewrite a plain old blocking application to a fully reactive stack the communication will consequently get faster. It’s not that simple.

Using something like Spring WebFlux will allow your application to use server resources more effectively, i.e. handle more concurrent requests on the same hardware. It may happen that requests will be completed faster because the server won’t be as overloaded as with a blocking stack. The communication itself won’t, however, change that much: while you will have a reactive flow of data inside your application code, the transmission over network won’t behave in a very responsive way.

If you have a client requesting multiple elements from a server with a REST HTTP request, the client will need to wait until the server ‘collects’ all results, no matter how reactive the code of client and server are. It can be visualised as follows:

The server does not send anything until it collects all 20 results, even though the code is reactive

This does not look very effective. If you want to shorten the client wait time, you need to change the communication method.

Streaming Responses

A more responsive way would be to send results one by one, as soon as each becomes available. In such a scenario, the client can start processing responses sooner. You can achieve this using RSocket protocol:

With RSocket the flow is smooth and everything finishes faster

RSocket isn’t the only way to achieve such an improvement. HTTP with Server-Sent Events will behave very similarly.

SSE appeared as a mechanism for streaming updates from the server to the browser, but it can be applied to server-server communication as well. Since it is a text protocol you can observe how the communication looks like.

While a conventional HTTP REST endpoint sends a big JSON array in an “all or nothing” manner, an SSE endpoint won’t return an array. Instead, it will send individual elements as JSON objects prefixed with data::

cURL gradually receiving data sent with Server-Sent Events

Handling Cancellation

So far we have considered improving the situation from the client’s point of view. However, using proper communication method will not only shorten the time of waiting for data but may also save server resources.

There are interaction types where a client queries a server but does not need all returned results. Let’s look at a very simplified case:

Mono<Result> findResult() {
    Flux<Result> results = getAllFromServer();
    return results

First, consider what happens if ‘plain’ HTTP is used. Here a reactive streams library (Project Reactor) will take care of canceling the reactive stream originating from the network connection to the server. This will free some resources on the client side, but no resources on the server side — the cancellation signal will come too late, already after the server will have finished all work:

The server produces all 50 results although client cancels request after consuming 9th result.

In contrast, when you stream responses using RSocket or Server-Sent Events, the server does not waste time and resources producing results that are not needed:

RSocket transmits client cancellation and server produces just 9 results.

This may result in a database connection being released sooner, less memory allocated for results to be sent to the client (and later garbage-collected) and so on.

RSocket Protocol

RSocket aims to bring reactive streams semantics to both server-server and server-browser communication and allow for performance optimizations not possible with HTTP.

There are three transport options that can be used with RSocket: TCP is the typical choice for the server-server variant, WebSocket will be more useful for server-browser variant and Aeron (UDP-based) can be used where throughput is really critical.

RSocket offers four interaction types. ‘Request-response’ and ‘request-stream’ are similar to HTTP REST interactions, where a server returns either one result or a collection of results to a client. ‘Fire-and-forget’ does not include any response, so it allows for certain optimizations. ‘Channel’ interaction allows for two-directional communication.

The protocol behaves like a reactive stream because it reserves a special field in frames it sends for the ‘request’ field, which holds client demand for elements and is an equivalent for Subscription.request() call in reactive streams. So when a client starts communication by sending REQUEST_STREAM or REQUEST_CHANNEL frame, the frame passes the initial request. A server is allowed to return only as many results as the current sum of the ‘request’ fields it has received. A client is able to increase the number by sending a REQUEST_N frame.

The client asks for 3 elements when sending the requests, and later asks for 7 more. The interaction ends with a payload frame including 'complete' bit.

With RSocket you can make the server produce data in the same cadence as the client requests it. This is because ‘request’ subscription calls in the reactive stream on the client side are transmitted in RSocket frames and cause same ‘request’ subscription calls on the server side.

request(6) call on the client side causes request(6) call on the server side

RSocket has some extra features like allowing a server to stop clients from sending too many requests (using LEASE frame) or allowing a client to resume transmission — but both are optional and may not be present in all implementations.

The Java implementation is closely coupled with Project Reactor library, exposing the Reactor’s implementation of reactive stream types:

Mono<Payload> requestResponse(Payload payload)
Mono<Void> fireAndForget(Payload payload)
Flux<Payload> requestStream(Payload payload)
Flux<Payload> requestChannel(Publisher<Payload> payloads)

Java implementation is also based on Netty and makes use of its zero-copy decoding capabilities.

RSocket is still a new thing. Its development started around 2015. In 2018 Spring Framework developers decided to add support for RSocket, which finished only in mid-2019. Since 2017 the protocol version is 0.2, which according to its creators should be considered ‘1.0 Release Candidate’. JavaScript implementation remains in version 0.0.19. There is not as much documentation and troubleshooting advice as with technologies that are present on the market for a long time.

Changing Code to Support Streaming

There is a huge difference between introducing Server-Sent Events to a project and doing the same with RSocket.

SSE is nothing much than a long HTTP response, with a different MIME type and different way of encoding elements. If your application is implemented in Spring WebFlux then having a ‘conventional’ endpoint like:

public Flux<CountStep> getAll(
        @RequestParam(defaultValue = "0") int delay,
        @RequestParam(defaultValue = "0") int max) {

You can expose an SSE-enabled one using a slightly different annotation and the framework will take care of the rest:

@GetMapping(path = "/all-stream",
        produces = MediaType.TEXT_EVENT_STREAM_VALUE)
public Flux<CountStep> getAll(
        @RequestParam(defaultValue = "0") int delay,
        @RequestParam(defaultValue = "0") int max) {

Similarly, changes to the client code aren’t significant. While a normal reactive HTTP client call looks like this:

return webClient.get().uri("/all")

SSE requires only a bit of additional unpacking:

ParameterizedTypeReference<ServerSentEvent<CountStep>> resultType =
        new ParameterizedTypeReference<>() {};
return webClient.get().uri("/all-stream")

If you look at a simple counterpart of HTTP endpoint implemented in RSocket, it may seem similar:

public Flux<CountStep> getAll(
        @DestinationVariable int delay,
        @DestinationVariable int max) {

Even so, RSocket works quite differently from HTTP and is designed as a message-based protocol. Spring Framework supports RSocket using spring-messaging library. Resources exposed with RSocket aren’t endpoints with paths, there are ‘routes’. The code may visually look similar, but it uses other annotations and the machinery handling those annotations is very different.

As we have seen at the beginning, typical tools like cURL can be used to peek into SSE communication. RSocket hasn’t gained such a mature ecosystem yet. Fortunately, there is a command-line tool called rsc that can be treated as a cURL equivalent.


Reactive web frameworks allow writing less resource-hungry clients and servers. However, if you want to speed up the end-to-end processing, you need to couple those frameworks with network protocols that support streaming, so that clients can start processing right from the first element, and not after receiving all results collected as it is the case with traditional HTTP.

Currently, there are 2 solutions: use Server-Sent Events or RSocket. Both support streaming results as they appear and canceling ongoing request that is no longer needed.

SSE is easier to introduce, as it is just a way of using HTTP. Code handling it is not much different from code using ’traditional’ HTTP communication. Yet it may be hard to achieve really high performance with it: there is no backpressure control and no way to use a compact and low-overhead encoding. For example, if you want to encode data with Protocol Buffers instead of JSON, SSE will transmit the payload encoded with Base64, as it is a text-based protocol.

RSocket gives you more options to tune for high performance, as it was designed for efficiency and does not need to follow HTTP semantics. It transparently transmits backpressure between client and server. It is a binary protocol, so sending Protocol Buffers-based payloads won’t get any text encoding penalty as with Base64 and SSE. On the other hand, it is a new technology, not yet stable and well-established. Code handling RSocket communication won’t look like the code using HTTP. Consider it if your system will be put under heavy load and your team is ready to put much effort into learning new things.

Source code for the demonstrated client-server interactions can be found on Github.

About the author

Piotr Kubowicz

Piotr Kubowicz

Software Engineer

Linkedin profile Twitter Github profile

Piotr is a polyglot developer who has been coding in Java for over ten years. He also tried many other languages, from C and Perl to Ruby.
During his time at nexocode, Piotr's primary focus has been on evolving team culture and ongoing projects by developing build automation and systems architecture to ensure delivery is smooth even as project codebases get bigger and more complex. As an active developer in the community, you can notice him speaking at various meetups and conferences.

Tempted to work
on something
as creative?

That’s all we do.

join nexocode

This article is a part of

Zero Legacy
36 articles

Zero Legacy

What goes on behind the scenes in our engineering team? How do we solve large-scale technical challenges? How do we ensure our applications run smoothly? How do we perform testing and strive for clean code?

Follow our article series to get insight into our developers' current work and learn from their experience. Expect to see technical details, architecture discussions, reviews on libraries and tools we use, best practices on software quality, and maybe even some fail stories.

check it out

Zero Legacy

Insights from nexocode team just one click away

Sign up for our newsletter and don't miss out on the updates from our team on engineering and teal culture.


Thanks for joining the newsletter

Check your inbox for the confirmation email & enjoy the read!

This site uses cookies for analytical purposes.

Accept Privacy Policy

In the interests of your safety and to implement the principle of lawful, reliable and transparent processing of your personal data when using our services, we developed this document called the Privacy Policy. This document regulates the processing and protection of Users’ personal data in connection with their use of the Website and has been prepared by Nexocode.

To ensure the protection of Users' personal data, Nexocode applies appropriate organizational and technical solutions to prevent privacy breaches. Nexocode implements measures to ensure security at the level which ensures compliance with applicable Polish and European laws such as:

  1. Regulation (EU) 2016/679 of the European Parliament and of the Council of 27 April 2016 on the protection of natural persons with regard to the processing of personal data and on the free movement of such data, and repealing Directive 95/46/EC (General Data Protection Regulation) (published in the Official Journal of the European Union L 119, p 1); Act of 10 May 2018 on personal data protection (published in the Journal of Laws of 2018, item 1000);
  2. Act of 18 July 2002 on providing services by electronic means;
  3. Telecommunications Law of 16 July 2004.

The Website is secured by the SSL protocol, which provides secure data transmission on the Internet.

1. Definitions

  1. User – a person that uses the Website, i.e. a natural person with full legal capacity, a legal person, or an organizational unit which is not a legal person to which specific provisions grant legal capacity.
  2. Nexocode – NEXOCODE sp. z o.o. with its registered office in Kraków, ul. Wadowicka 7, 30-347 Kraków, entered into the Register of Entrepreneurs of the National Court Register kept by the District Court for Kraków-Śródmieście in Kraków, 11th Commercial Department of the National Court Register, under the KRS number: 0000686992, NIP: 6762533324.
  3. Website – website run by Nexocode, at the URL: whose content is available to authorized persons.
  4. Cookies – small files saved by the server on the User's computer, which the server can read when when the website is accessed from the computer.
  5. SSL protocol – a special standard for transmitting data on the Internet which unlike ordinary methods of data transmission encrypts data transmission.
  6. System log – the information that the User's computer transmits to the server which may contain various data (e.g. the user’s IP number), allowing to determine the approximate location where the connection came from.
  7. IP address – individual number which is usually assigned to every computer connected to the Internet. The IP number can be permanently associated with the computer (static) or assigned to a given connection (dynamic).
  8. GDPR – Regulation 2016/679 of the European Parliament and of the Council of 27 April 2016 on the protection of individuals regarding the processing of personal data and onthe free transmission of such data, repealing Directive 95/46 / EC (General Data Protection Regulation).
  9. Personal data – information about an identified or identifiable natural person ("data subject"). An identifiable natural person is a person who can be directly or indirectly identified, in particular on the basis of identifiers such as name, identification number, location data, online identifiers or one or more specific factors determining the physical, physiological, genetic, mental, economic, cultural or social identity of a natural person.
  10. Processing – any operations performed on personal data, such as collecting, recording, storing, developing, modifying, sharing, and deleting, especially when performed in IT systems.

2. Cookies

The Website is secured by the SSL protocol, which provides secure data transmission on the Internet. The Website, in accordance with art. 173 of the Telecommunications Act of 16 July 2004 of the Republic of Poland, uses Cookies, i.e. data, in particular text files, stored on the User's end device.
Cookies are used to:

  1. improve user experience and facilitate navigation on the site;
  2. help to identify returning Users who access the website using the device on which Cookies were saved;
  3. creating statistics which help to understand how the Users use websites, which allows to improve their structure and content;
  4. adjusting the content of the Website pages to specific User’s preferences and optimizing the websites website experience to the each User's individual needs.

Cookies usually contain the name of the website from which they originate, their storage time on the end device and a unique number. On our Website, we use the following types of Cookies:

  • "Session" – cookie files stored on the User's end device until the Uses logs out, leaves the website or turns off the web browser;
  • "Persistent" – cookie files stored on the User's end device for the time specified in the Cookie file parameters or until they are deleted by the User;
  • "Performance" – cookies used specifically for gathering data on how visitors use a website to measure the performance of a website;
  • "Strictly necessary" – essential for browsing the website and using its features, such as accessing secure areas of the site;
  • "Functional" – cookies enabling remembering the settings selected by the User and personalizing the User interface;
  • "First-party" – cookies stored by the Website;
  • "Third-party" – cookies derived from a website other than the Website;
  • "Facebook cookies" – You should read Facebook cookies policy:
  • "Other Google cookies" – Refer to Google cookie policy:

3. How System Logs work on the Website

User's activity on the Website, including the User’s Personal Data, is recorded in System Logs. The information collected in the Logs is processed primarily for purposes related to the provision of services, i.e. for the purposes of:

  • analytics – to improve the quality of services provided by us as part of the Website and adapt its functionalities to the needs of the Users. The legal basis for processing in this case is the legitimate interest of Nexocode consisting in analyzing Users' activities and their preferences;
  • fraud detection, identification and countering threats to stability and correct operation of the Website.

4. Cookie mechanism on the Website

Our site uses basic cookies that facilitate the use of its resources. Cookies contain useful information and are stored on the User's computer – our server can read them when connecting to this computer again. Most web browsers allow cookies to be stored on the User's end device by default. Each User can change their Cookie settings in the web browser settings menu: Google ChromeOpen the menu (click the three-dot icon in the upper right corner), Settings > Advanced. In the "Privacy and security" section, click the Content Settings button. In the "Cookies and site date" section you can change the following Cookie settings:

  • Deleting cookies,
  • Blocking cookies by default,
  • Default permission for cookies,
  • Saving Cookies and website data by default and clearing them when the browser is closed,
  • Specifying exceptions for Cookies for specific websites or domains

Internet Explorer 6.0 and 7.0
From the browser menu (upper right corner): Tools > Internet Options > Privacy, click the Sites button. Use the slider to set the desired level, confirm the change with the OK button.

Mozilla Firefox
browser menu: Tools > Options > Privacy and security. Activate the “Custom” field. From there, you can check a relevant field to decide whether or not to accept cookies.

Open the browser’s settings menu: Go to the Advanced section > Site Settings > Cookies and site data. From there, adjust the setting: Allow sites to save and read cookie data

In the Safari drop-down menu, select Preferences and click the Security icon.From there, select the desired security level in the "Accept cookies" area.

Disabling Cookies in your browser does not deprive you of access to the resources of the Website. Web browsers, by default, allow storing Cookies on the User's end device. Website Users can freely adjust cookie settings. The web browser allows you to delete cookies. It is also possible to automatically block cookies. Detailed information on this subject is provided in the help or documentation of the specific web browser used by the User. The User can decide not to receive Cookies by changing browser settings. However, disabling Cookies necessary for authentication, security or remembering User preferences may impact user experience, or even make the Website unusable.

5. Additional information

External links may be placed on the Website enabling Users to directly reach other website. Also, while using the Website, cookies may also be placed on the User’s device from other entities, in particular from third parties such as Google, in order to enable the use the functionalities of the Website integrated with these third parties. Each of such providers sets out the rules for the use of cookies in their privacy policy, so for security reasons we recommend that you read the privacy policy document before using these pages. We reserve the right to change this privacy policy at any time by publishing an updated version on our Website. After making the change, the privacy policy will be published on the page with a new date. For more information on the conditions of providing services, in particular the rules of using the Website, contracting, as well as the conditions of accessing content and using the Website, please refer to the the Website’s Terms and Conditions.

Nexocode Team


Want to be a part of our engineering team?

Join our teal organization and work on challenging projects.