Re: RSocket Followup (post TOC meeting)
Yes, that’s right. I’m not sure where the notion that Go doesn’t do async well came from. In my experience golang does just fine using channels and go routines.
Here’s a fairly useful article for anyone interested in the topic: https://medium.com/@alexyakunin/go-vs-c-part-1-goroutines-vs-async-await-ac909c651c11
On a different note, on the call I asked a question related to application flow control, but we ran out of time before being able to explore it fully.
My question is basically this:
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?
Technical Vice President
America Research Center
2330 Central Expressway, Santa Clara, CA 95050
Tel: 408-330-4721 Cell: 408-320-8917 Office # E2-9
Email: quinton.hoole@... ID#Q00403160
From: <cncf-toc@...> on behalf of Robert Roeser <robert@...>
Date: Wednesday, August 8, 2018 at 18:00
To: Justin Cormack <justin.cormack@...>, Chris Aniszczyk <caniszczyk@...>
Cc: CNCF TOC <cncf-toc@...>, Robert Roeser <robert@...>, Ben Hale <bhale@...>
Subject: Re: [cncf-toc] RSocket Followup (post TOC meeting)