Re: RSocket Followup (post TOC meeting)


Ben Christensen
 

> why did you feel it necessary to add an additional layer of application flow control on top of what TCP already provides?
 
This is discussed in the FAQ of the project:  https://github.com/rsocket/rsocket/blob/master/FAQ.md#why-reactive-streams-requestn-flow-control
 
The key difference is that RSocket offers end-to-end instead of hop-to-hop flow control and expects to have message-level flow control exposed through APIs into the application layer. This allows non-blocking bounded message queues in user code and prevents buffer bloating of intermediaries. 
 
A key example is an experience I had with a load balancer (TCP, not HTTP in that case) where the hop-to-hop behavior did what it does best - filled the entire buffer of the proxy (load balancer) - which resulted in increasing latency of the end consumer (fast producer, slow consumer problem) until eventually the proxy would OOM and reboot. This required bad hacks to address since the protocol in use did not support end-to-end flow control. Neither HTTP or TCP expose end-to-end flow control mechanisms into the application layer, RSocket allows this. 
 
The responses from Ben Hale earlier also did a good job of explaining this and provided further examples I won't repeat here. 

Join cncf-toc@lists.cncf.io to automatically receive all group messages.