helidon
helidon copied to clipboard
helidon-io
RSocket support. First Iteration.
Related to #3046
RSocket integration proposal
About RSocket
RSocket is an application protocol initially developed by Netflix that supports Reactive Streams. The motivation behind its development was to replace hypertext transfer protocol (HTTP), which is inefficient for many tasks such as microservices communication, with a protocol that has less overhead.
RSocket is a binary protocol for use on byte stream transports such as TCP, WebSockets, and Aeron. It enables the following symmetric interaction models via async message passing over a single connection:
- request/response (stream of 1)
- request/stream (finite stream of many)
- fire-and-forget (no response)
- channel (bi-directional streams) It supports session resumption, to allow resuming long-lived streams across different transport connections. This is particularly useful for mobile‹–›server communication when network connections drop, switch, and reconnect frequently.
Proposal
Current support is the experimental first iteration, and subject of change since the major Routing behaviour in Helidon may change in version 3.0.
The current proposal implements:
- SE and MP API similar to gRPC, but with the respect to RSocket particular features;
- MP Custom API annotation set is made.
- At the current stage, reuse Tyrus module, since RSocket is quite similar;
- Custom routing in RSocket to fit Helidon API implemented;
- Examples are provided;
- RSocket configuration done via Helidon Config.
- All Reactor API are hidden or replaced from Helidon APIs
Only WebSocket transport currently supported.
Mostly focused on the code, not so much on the project files. This looks good to me. It would have been nice to submit this in multiple PR's, e.g., separating metrics and health check; it is just hard to go over 5K lines of code in one shot.
Thank you very much, Santiago :) Will do split next time :)
For the info - latest rsocket/rsocket-java 1.1.1 is vulnerable to several
trivial denial-of-service attacks (memory overflow, file descriptors exhaustion) 1, 2, 3, 4 - so servers are unsafe with 3rd party clients. AFAIK only 1 vuln of 4 was being worked on (though no new release was made for 5 month now),
others are ignored - which may imply these need to be somehow handled in helidon, or state explicitly in docs that servers are safe with 1st party clients only.
