RSocket starts from the premise of a socket. Sockets are a tried and true mechanism to open a connection, transmit data, receive data, and continue.
There are four paradigms of RSocket:
In a request/response model, each request receives a single response.
This approach probably solves 80% of our problems. There are lots of things we must all do that use this. Requesting a piece of data from a remote service, submitting a new record and waiting for confirmation, and many more things can be captured using this mechanism.
In this model, a single request receives multiple responses. Hence, this is a more efficient implementation of “make a request” and listening for a stream of responses.
RSocket lets you open the channel, send your request, and wait for a stream of responses without holding up any threads.
An excellent example of Request/Stream is requesting a stream of updates from a brokerage API for updates on our favorite stock symbol. The updates can arrive at any time. Our code doesn’t care. It does not mean the server can transmit 100,000 updates all at once. With reactive programming underpinning RSocket, you can say, “send me the next ten updates.”
In this model, the client will receive no response from the server. In short, the client will send a request and will not wait or expect the server to send back a response.
Hence, when the server responds, that response must be coordinated with the original request. Often they use correlation ids, which introduce all sorts of logistics.
This model is a bidirectional communication model. This means message streams flow asynchronously in both directions.
In the above three RSocket paradigms, the client is always initiating the request. However, in the channel paradigm, communication is two-way.
Either side of the channel can transmit messages to the other side. And each side must essentially register a reactive message listener.
View all Courses