1. Cncf-Toc
  2. Messages

Re: RSocket Followup (post TOC meeting)

Quinton Hoole
 

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?

Thanks

Q
   

Quinton Hoole

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)

Hi Justin,

From the go people I talked with we can use go channels for request stream and request channel. For request / response and fire forget people could be a use a go routine. I am not a go expert but understanding is that you could use buffered channels with the RSocket request n semantics effectively.

I was told the interfaces could be idiomatic go.

Thanks,
Robert

Get Outlook for iOS
From: Justin Cormack <justin.cormack@...>
Sent: Wednesday, August 8, 2018 3:27:23 PM
To: Chris Aniszczyk
Cc: CNCF TOC; Robert Roeser; Ben Hale
Subject: Re: [cncf-toc] RSocket Followup (post TOC meeting)
 
The Go question came up in the call, which is interesting as much of the CNCF ecosystem is currently
Go based, although diversifying. Go is unusual in not supporting async interfaces really, prefering
to do explicit sync threading. The rsocket protocol is just a wire protocol, but I am curious if anyone
has looked at what the programming interface for Go might look like and whether maintaining this
might be an issue.


On Tue, Aug 7, 2018 at 5:04 PM, Chris Aniszczyk <caniszczyk@...> wrote:

I just wanted to move this discussion to the mailing list as there was some questions that weren't answered and I know that Colin had some feedback on the project comparisons (rsocket vs nats vs grpc)

Also Alexis Richardson from the TOC is OK to sponsor this effort into the Sandbox, so if anyone else is interested in sponsoring, please let me know.

Feel free to continue the discussion here.

--
Chris Aniszczyk (@cra) | +1-512-961-6719
Join cncf-toc@lists.cncf.io to automatically receive all group messages.