Re: RSocket Followup (post TOC meeting)
I'd like to add to Ben's comments that this pattern is implemented in many message brokers which de facto support relays a->b->c.toggle quoted message Show quoted text
The appeal (to me) of rsocket is to make the pattern part of the protocol and remove the requirement for a broker.
However, to then be useful it is critical that multiple implementations exist and interoperate.
On Fri, 10 Aug 2018, 19:36 Ben Hale, <bhale@...> wrote:
> A pretty common way that application flow control is achieved in TCP-based distributed systems is for a message consumer to simply stop reading messages off a TCP connection if it wants the message producer to stop sending messages from the other end. TCP does all the rest automatically, compliments of sliding windows, receive buffers etc. If senders and receivers use fairly basic thread pools, back pressure through the system “just works”, in my experience. It sounds like a fairly significant part of Rsocket is an additional protocol to achieve much the same back-pressure-based application flow control? Other than to support non-TCP transports (like UDP), which I would assume are fairly uncommon, why did you feel it necessary to add an additional layer of application flow control on top of what TCP already provides?