RSocket

[arnavdesai82]

While there is support for gRPC in Vert.x , RSocket is an interesting and fast way to communicate between reactive microservices. I am hoping Vert.x would consider adding support for RSocket as well.

http://rsocket.io/

On that note - is there any commonalities between the R2DBC spec/drivers for Relational DB and the new Vert.X driver coming in 4.0 ?

[1017727621]

Yes I agree It's so fast and better than http

[hutchig]

Is there already material out there that compares Vert.x today with what RSocket support would add so that we could understand what user benefits this feature would bring?

[vietj]

Which protocol RSocket aims to replace ?

[arnavdesai82]

RSocket is an OSI layer 5/6 so it would be something even lower than gRPC. More details -->https://medium.com/netifi/differences-between-grpc-and-rsocket-e736c954e60 I believe its main purpose is to reduce to communication overhead in between services in addition to providing a reactive way for communication. While I could not locate material for Vert.x specifically, there is some decent material as well as code on RSocket specifically. For example the motivations and details behind the protocol are listed clearly here http://rsocket.io

[vietj]

@arnavdesai82 I've read quickly what RSocket does and indeed it provides a very bare bones event-bus (Vert.x) like protocol on top of a reliable unicast transport. The closest thing we do have in Vert.x is the event-bus protocol.

So as I see it

• we could support RSocket with a simple Vert.x integration so RSocket client/server work in a Vert.x application (i.e they use Vert.x resources and concurrency model). In this case it is up to the application to define its own usage of the message payload.
• we could use RSocket protocol as an Event-Bus transport replacement
  • the Event-Bus provides the service topology (naming / lookup)
  • Vert.x service proxies is the RPC (comes for free)

[arnavdesai82]

I will be honest and totally admit that I had not thought about it being used within the event bus, my initial thought process was for supporting communication (using the RSocket protocol) in between microservices hence a simple implementation within the library (of a client & server) would suffice.

Now that you have mentioned it though , the replacement for the Event-Bus transport also sounds promising for the reasons you mentioned.

[vietj]

@arnavdesai82 I believe that RSocket is definitely missing a programming model (as it is not the intent), I don't foresee developers using it for building their application instead of HTTP / gRPC or messaging (Kafka).

[arnavdesai82]

That's interesting because in all the examples I have seen , the most basic example is the Request/Response method of communication which is exposed via RSocket. For instance, this example done using Spring (I only use them here as an example) supports multiple ways of communication. It also has a streaming example. https://www.baeldung.com/spring-boot-rsocket

I see this form of communication being useful as well (i.e. replacing HTTP transparently to the programmer). Some other sources I was looking at when seeing this as being useful would be https://grapeup.com/blog/read/reactive-service-to-service-communication-with-rsocket-introduction-63

Also while I would be wary of the claims being made here due to them being made by the folks behind RSocket- I do think the results look promising. https://medium.com/netifi/evaluating-critical-performance-needs-for-microservices-and-cloud-native-applications-7675c50a8460

[vietj]

In the example you provide, there is a programming model on top of RSocket which is provided by Spring annotations and magic.

The MarketDataRSocketController is annotated with Controller and MessageMapping I think serialise and unserialise the MarketData and MarketDataRequest beans. Without this RSocket is very low level.

I don't understand what you mean by replacing HTTP transparently to the programmer can you elaborate ?

[arnavdesai82]

I think you hit what I was trying to say within your second paragraph. The RSocket integration I had originally envisioned was for the purposes of simplifying the implementation details of request/response especially as you have already stated that RSocket is very low level for most users.

While Spring does hide away all the details behind 'magic' , for Vert.x I still feel it would worth to abstract away some of the complexity of RSocket.

[hutchig]

It was only "use RSocket protocol as an Event-Bus transport replacement" that I was wondering about, so the programming model would initially remain as Vert.x services/events and the things built on that (Quarkus/SmallRye reactive messaging?).

One might think that this would be just 'box ticking' with something that is trendy, particularly without any comparative measurements of performance gains/losses given that Vert.x EventBus might already provide many/all? of the stated RSocket benefits. Needs empirical data. In "Hands on Reactive Programming in Spring 5" by Oleh Dokuka (@OlegDokuka) and Igor Lozynskyi (@aigor) section "RSocket versus Reactor-Netty" there is a long-form argument for taking reactive into the netty (replacement) layer rather than sitting on top.

One thing that might be worth considering is if there was a neutral 'standard' (e.g. reactivestreams.org interfaces) mapping to the RSocket layers'...not sure if this would come from https://reactive.foundation/ or if their answer would be Reactor flavoured.

The project I am interested in is to put Vert.x as a Connector/transport for inter-server OpenLiberty Reactive Messaging and whether having RSocket underneath Vert.x's event bus would measurably improve things for users in any way.

[vietj]

@hutchig I think performance wise it would not make a difference (this is of course very speculative based on the fact that the EB protocol is simple and efficient (prefixed based binary protocol like HTTP/2 or RSocket itself)). One improvement that RSocket currently does have that is not in Vert.x EB Protocol is the fragmentation of payload in multiple packets, that can be an issue when sending/receiving large payloads.

[OlegDokuka]

Hello everyone . RSocket core team engineer there.

The intent of RSocket is to eliminate all the gaps of previous generation Application protocols like HTTP (1 1.1 2 ) which were not designed for doing microservices communication (mostly browser stuff).

RSocket in nutshell provides a wide communication model including common patterns like Request-Response, Request-Streams, Bidi-Streaming, Fire-And-Forget (also there is metadata-push for metadata exchange) (for more info see the following.

The intent for RSocket as a protocol is to provide a foundation for cloud-native messaging where common enterprise problems like resilience, efficiency are built-in features of the protocol. For example, see there how rate-limiting / circuit breaker becomes redundant with leasing. Or the fact that Reactive-Streams Backpressure is the first-class citizen of the protocol and allows transparently sending your reactive streams over the network. Or, how naturally protocol solves common HTTP / TCP problem of streams` resuming in case of mobile devices which are frequently changing the source of the network (e.g wifi->4G->3G-wifi).

So, all those things are just a small part of the iceberg and apart from that we provide a proper user experience on top of RSocket. For example, there is RSocket-IPC which lets you just simply replace your gRPC without significant rewriting of the application.

Thus, there is a place of RSocket which enables most of the applications to get rid of old wasteful HTTP and similar protocols.

[OlegDokuka]

To clarify, RSocket could be a separate way of doing interaction between services in vert.x and could be a way to wire P2p communication within a cluster. What I would propose as a good startpoint is implementing ServerTransport / ClientTransport interfaces within Vert.X and expose straightforward configuration which can give an RSocket Client/Server capabilities for ordinary engineers.

Let me know if you need any help / clarification of the spec or RSocket ecosystem

[pipinet]

https://github.com/smallrye/smallrye-reactive-messaging/issues/524

[hero-zhanghao]

Hello, everyone, I want to know the progress. Will RSocket be supported in the future?

[vsigler]

I'm going to do a ping as well since it's been 6 months since the last one. Do we expect rSocket support to happen in near future?

[cch0]

Fast forward to 2024, have we had new or different thought on this subject?

[OlegDokuka]

I can happily work on the implementation with someones assistance