Websockets vs Reactive sockets

Question

I have recently come across a term 'Reactive sockets'. Up until this point, I used to think websockets are the way to go for full fledged asynchronous style.

So what are reactive sockets.

This link (http://rsocket.io/) even talks about comparison over websockets.

Gibbous

Could you explain why this question is down voted? – Gibbous

Answer 1

What is RSocket?

RSocket implements the Reactive Streams specification over the network boundary. It is an application-level communication protocol with framing, session resumption, and backpressure built-in that works over the network.

RSocket is transport agnostic. RSocket can be run over Websockets, TCP, HTTP/2, and Aeron.

How does RSocket differ from Websockets?

Websockets do not provide application-level backpressure, only TCP-based byte-level backpressure. Websockets also only provide framing they do not provide application semantics. It is up to the developer to build out an application protocol for interacting with the websocket.

RSocket provides framing, application semantics, application-level backpressure, and it is not tied to a specific transport.

For more information on the motivations behind the creation of RSocket checkout the motivations doc on the RSocket site.

Protector

gregwhitaker Could please help to understand what's application-level backpressure and byte-level backpressure? It would be great if you can explain with example. – Kepner

Sure, byte-level backpressure is where the receiver says "send me x number of bytes". Application-level backpressure is where the receiver says "send me x number of domain or request objects" – Protector

Link to motivations doesn't work. Here is the correct one: rsocket.io/about/motivations – Pavel

Answer 2

Both WebSocket and RSocket are protocols which feature bi-directional, multiplex, duplex communication. But both work at different levels.

WebSocket is a low level communication protocol layered over TCP. It defines how a stream of bytes is transformed into frames. But WebSocket message itself does not have instructions about how to route or process it. Therefore, we need messaging protocols that operate on top of websocket, at application level, to achieve two-way communication.

RSocket is a fully reactive application level protocol which runs over byte stream transports such as TCP, WebSocket, UDP or other. It provides application flow control over the network to prevent outages and increase resiliency. RSocket employs the idea of asynchronous stream processing with non-blocking back-pressure, in which a failing component will, rather than simply dropping traffic, communicate its stress to upstream components, getting them to reduce the load.

Radmen

I wish I could give you more than one point because this explanation was really nice – Mantelet

Answer 3

Websocket

TLDR: L4 protocol, TCP for web.

Websocket is single bytestream, frames based protocol with very compact header.

It relies on web/http in each important protocol aspect: http based handshake (full roundtrip, not ideal for latency), text frames in addition to binary ones, compression support (for low-throughput/high latency connections), mandatory frame content masking for compatibility with legacy non-tls http proxies.

Frames may be fragmented for better memory utilization by client and server;

Flow control is byte level only from TCP, and is not propagated to userspace.

Because websocket is just single bytestream transport, It needs full application protocol on top to be useful, and application level flow control scheme to be scalable.

Adoption wise, stable websocket implementation is available for most OSes / architectures, protocol is supported by all browsers and is go-to solution if any traffic needs to survive internet hop.

RSocket. Theory

TLDR: L5 protocol, primarily cloud/datacenter communications with excellent throughput/latency characteristic: huge throughput while maintaining latency < few millis.

RSocket is session layer protocol, offers multiplexed flow controlled streams of binary messages over any transport capable of transferring bytes in order (tcp, unix sockets, also websocket).

Low latency is cornerstone, protocol has several capabilities for this:

• 2 levels of flow control: Reactive-Streams on individual stream level, request leasing on connection level. Leasing is feature to control number of active streams by responder side using service & connection latency stats.
• Instant handshake: client may send requests immediately after initial setup message.
• Message fragmentation helps with reducing server memory pressure and improves latency for large messages (if done properly, see RSocket. Practice below).
• Session resumption: reduced latency on client reconnection.

Because binary streaming interactions / multiplexing are available out-of-the-box, It is trivial to implement application RPC on top - only data serialization/deserialization is needed (mstreams-rpc using protobuf data encoding).

The protocol is semantically compatible with http2, which means It is also compatible with GRPC (given protobuf is used for message encoding).

RSocket. Practice

Only useful on JVM because that's where reactive streams are popular and practically useful with several stable implementations: rxjava, project-reactor, smallrye-mutiny.

RSocket/RSocket-java is based on project-reactor from springboot.

Natural expectation would be best-in-class throughput, unfortunately RSocket/RSocket-java did not get this right so performs worse than 10+ year older GRPC (its predecessor Stubby was in use from ~2001) on top of http2: chatty web protocol.

Fragmentation: no server memory use or latency improvement because RSocket/RSocket-java implemented It in pointless way - frames are always reassembled before passing downstream.

GRPC compatibility: absent.

Advice for 2022: better stick with GRPC.

Conoid