Yep, you enable chunked encoding and return many messages. But there are some subtle problems with that. I worked with such code and do not recommend it.

@@ImaskarDono naa.. no need for chunk encoding. Just put "produces" header as octet/stream and then write to output stream as much and as frequently as you want (obviously constraint by configured timeouts) and you're good

@@Sagar13iffy spring will set it for you automatically, I just wrote how it works on the protocol level.

@@ImaskarDono ahh I see.. I too have such a code running in production. Didn't face any issue yet. Why do you not recommend it?

@@Sagar13iffy can't detect connection problems, exchange may get stuck forever.

RSocket can *use* tcp/ip connections, it is an alternative to the HTTP protocol (application level, not transport level).

Well, why not stick to old BBS messaging system instead of inventing KZfaq comments section? "Reinventing the wheel" means innovation and keeping human's brain warm. If we don't do it anymore, soon enough we won't even be able to think.

why not?

for rsocket?

what are you talking about? this framework is for java

Go java ;-) and that biggest problem of yours is solved like magic!

It's different than gRPC in that it isn't based on HTTP2 and it doesn't require google protocol buffs for payloads. RSocket can run on things like Aeron and TCP and WebSockets, not just TCP like HTTP2. See rsocket.io/docs/FAQ.html for answers to some questions like "Why not...". Also, the fact that it can run on WebSockets/Aeron/TCP (vs just TCP) isn't BS. Some of the largest websites on the planet use RSocket + WS at scale. I haven't used the Aerson implementation but I have no reason to doubt that it's there for a reason. And for that matter, I have no reason to doubt that it's an awesome choice given how powerful Aeron is. I hope these answers help, and next time, please do your best to pose interesting questions without resorting to the vulgarities, eh? I'm certainly no saint but I try to do better on the Spring YT channel because younger people sometimes watch these tech videos... thanks.

@@coffeesoftware Hi, I meant more if it's throughput performance you want, you'd go for gRPC but you'd deal with protobufs, yes. If it's JSON you plan on transfering, the current spring-reactor is probably sufficient. WS endpoint is covered as well in "traditional" spring-reactor. There is probably some performance to go with tcp that you'd not have in spring-reactive, for not having to deal with http headers. I don't want my comment to appear as inconsiderate of the work, I'm just missing the 'revolutionary' spark. I still didn't find the Aeron implementation - I was expecting it on some kind of aeron-transport module github.com/rsocket/rsocket-java, or in the examples github.com/rsocket/rsocket-java/tree/master/rsocket-examples/src/main/java/io/rsocket/examples/transport

@@MrSpamTrapper I can actually attest to using RSocket as a unified HTTP/S and Websockets server. In our case, we have legacy hardware platforms and customers to support that cannot speak a modern version of TLS, but the demand from mobile customers has pretty much necessitated having HTTP2 support. We don't have the luxury of a microservices platform, so the solution has to fit both use cases. For now, we can leverage Websockets on the legacy hardware platforms to get around having to split the production environment, but we are looking at Aeron and Google QUIC (HTTP(3) over UDP) support in RSocket as a way to cover both legacy and current hardware along with the mobile clients with minimal resources and de-duplication of code. It just comes down to "if" we can fit the needed network stack components in the legacy systems' memory. I will admit the use case where you'd have HTTP AND a non-TCP endpoint on the same system--speaking two very different protocols--is niche, but think about all of the embedded systems out in the wild that have to stay hardened against bad actors on the net.

不明白