|
Chris Aniszczyk
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
|
|
|
Colin, your feedback is essential, please do share
Rsocket team, key questions for me are:
- what are main differences/USPs Vs prior art (nats, grpc, 0mq) - is rsocket more of a lib or a "product' - what's the Go story?
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
|
|
|
Thanks for the presentation.
It looks like the project has existed for about 3 years? Has it not actively sought contributors or users up to now? Development looks not very active and it has < 300 github stars.
What did the "language agnostic" point mean? Just that it has implementations in multiple languages (at least Java and C++ -- it's not clear which other languages are actively maintained/developed)?
On Tue, Aug 7, 2018 at 9:04 AM 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
|
|
|
Great presentation, RSocket is an interesting project - the flow control handling with the lease based model is impressive. Speaking for myself and the NATS team, we’re happy to see more messaging related projects being proposed, giving CNCF end users more options to find the best fit for their use case.
In the past I’ve made product comparisons with incomplete information - it was a learning experience, and Alexis can vouch for that. :) To that end, what does the TOC think of having public comparison cards for related projects, where project maintainers would provide their own input on their feature sets, implementation details, etc? I think something along those lines would go a long way to help users educate themselves about different projects without bias, and this would facilitate the CNCF in providing guidance to end users.
In the slides, there are a few things I’d like to clarify. But first, any suggestions on how we can improve our documentation to make our feature set and implementation details clearer would be much appreciated. My general clarification here is that while NATS uses a simple text based protocol, we are payload agnostic, supporting payloads of any type, including binary.
We do appreciate the product comparison. Here is some more detailed clarification.
Slide 36:
- Binary - Is this referring to the protocol or payload support? ...NATS does supports binary payloads.
- Max Payload Size - NATS can be configured to be effectively “unlimited”, although the default is 1MB.
- Browser support: To clarify, for NATS support is via third party but maintainer support is coming soon.
- Bidirectional Channel: Maybe N/A for NATS?. We support multiple streams (subjects) under a request/reply API, but at a lower level all of NATS is async.
Slide 37:
- Inline Errors - N/A, we provide asynchronous error notifications.
Slide 38
- NATS Languages - See https://nats.io/download/
- Reactive Streams Support - Third Party
- IPC - The protocol is text, but payloads are binary (payload agnostic).
- Creators - We credit Derek Collison as the creator of NATS rather than a specific company or organization.
Again, we’re really happy to see more messaging projects proposed, and I hope this can clarify to create a more accurate project comparison. I’d love to hear what people think about some sort of public feature set comparison, endorsed by the CNCF.
Thanks,
Colin
|
|
|
Robert Roeser <robert@...>
Has it not actively sought contributors or users up to now?
The project hasn’t sought active contributors until now.
What did the "language agnostic" point mean?
RSocket is spec’d protocol (https://github.com/rsocket/rsocket/blob/master/Protocol.md), and not dependent on a language features for implementation. Right now, there are implementations
in Java, Javascript, C++, and Kotlin. There is interest in Python and Golang implementation, and plans to implement these.
From:
Brian Grant <briangrant@...>
Date: Tuesday, August 7, 2018 at 9:24 AM
To: Chris Aniszczyk <caniszczyk@...>
Cc: cncf-toc <cncf-toc@...>, Robert Roeser <robert@...>, "bhale@..." <bhale@...>
Subject: Re: [cncf-toc] RSocket Followup (post TOC meeting)
Thanks for the presentation.
It looks like the project has existed for about 3 years? Has it not actively sought contributors or users up to now? Development looks not very active and it has < 300 github stars.
What did the "language agnostic" point mean? Just that it has implementations in multiple languages (at least Java and C++ -- it's not clear which other languages are actively maintained/developed)?
toggle quoted message
Show quoted text
On Tue, Aug 7, 2018 at 9:04 AM 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
|
|
|
Robert Roeser <robert@...>
+stevegury@...
Hi,
Here’s answers to your questions below. Please reach out to Ben Hale, Steve Gury, or myself if you have additional questions
Thanks,
Robert Roeser
Rsocket team, key questions for me are:
- what are main differences/USPs Vs prior art (nats, grpc, 0mq)
- RSocket is essentially distributed RxJava or ReactiveStreams
- RSocket client and server both have a requester and responder. This means that either side of an RSocket connection can initiate a stream. This lets you do interesting things like have
a mobile device connect to a microservice, and then allow the server to make calls directly to the mobile device - as if the mobile device was a server. The mobile device could serve a stream of GPS coordinates, log data, etc.
- RSocket complements ReactiveStreams - ReactiveStreams abstracts asynchrony within a binary boundary (threads, etc) and RSocket abstracts this across a binary boundary (network calls)
- RSocket abstracts the transport from the developer - an application written with RSocket supports whatever transports are implemented.
- The transport abstraction lets you pick a transport appropriate to your environmental constraints. For instance, if you're working with a web browser you can use WebSocket and if you're
in a data center you can use something with higher throughput like Aeron UDP protocol. The developer would not need to change their application logic, just replace the transport RSocket is using.
- Support for ReactiveStreams request n style flow control across a binary boundary
- Request n works by a stream consumer sending the producer the number of items it wants to consume. In RSocket it receives REQUEST_N frame with a number indicating how many items to produce.
- This application level back-pressure is composeable across services
- Optional Leasing support - applications send other applications leases in the form of X requests can be sent of the next Y seconds. Load balancers can use this information to direct traffic
to other services that have capacity.
- Leasing and Back-pressure can obviate the need for additional circuit breakers and rate limiters
- RSocket cancellations are propagated up and down across chains of services - and because ReactiveStreams is lazy this can cancel work before it has started - this is beneficial in error
conditions because it will be prevent extra/wasteful processing.
- Each RSocket connection is a bidirectional stream that arbitrages flow control between transport back-pressure and application back-pressure
- All interactions are modeled as asynchronous streams with optimizations for the different interaction models
- Request/reply - bi-directional stream of one to one
- Fire/Forget - unidirectional stream of one
- Request/Stream - bidirectional stream of one to many
- Request/Channel - bidirectional stream of many to many
- RSocket supports metadata push which you can use to push metadata associated with a connection.
- RSocket can support many thousands of concurrent streams on a single host
- Resumability is handled at the protocol/implementation level, so while this is possible today, the protocol removes it as an application concern. For instance, this lets a developer
work with a flappy network connection as if it's a reliable one. This is particularly useful for mobile developers. This lets you keep your subscriptions active and then RSocket sends missing data when a connection is reestablished.
- gRPC is a RPC on HTTP/2 and I believe was created to leverage existing infrastructure. gRPC's spec is a collection of headers and URLs- in its current implementation it requires something
like HTTP/2 vs RSocket which is a binary framed protocol and can send it over any bi-directional connection. RSocket works in a browser whereas gRPC needs a bridge. You could use RSocket as a layer to building something like gRPC that could run over multiple
layers, rather than being tied to HTTP/2
- NATs is a message broker and a product. NATs requires an external broker, is text based. RSocket is library you would include in your application. You would use RSocket to build something
like NATs
- 0mq is similar in some requests, but IMO the RSocket protocol is simpler than 0mq. Messages in 0mq are blobs, and RSocket payloads have the concept of data and metadata each with their
own mime-type. 0mq is intended to model a message broker vs RSocket which is "distributed RxJava". 0mq doesn't work in a web browser whereas RSocket does.
- is rsocket more of a lib or a "product'
RSocket is a library for network communication like `javax.net` or gRPC. Applications are built upon it, but since it does not _require_ an intermediate broker, there's no product required.
An intermediate broker _can_ be useful and be a product, but this is a transparent addition that is not required by RSocket.
- what's the Go story?
We need to implement a version in Go. We have talked with various parties and there is interest in it. It is not the various RSocket teams core competency, but there is nothing stopping
an implementation from being made as either wrapping the C++ library, or writing a pure golang implementation. We would be happy to help with its implementation.
From:
Alexis Richardson <alexis@...>
Date: Tuesday, August 7, 2018 at 9:14 AM
To: Chris Aniszczyk <caniszczyk@...>
Cc: Ben Hale <bhale@...>, CNCF TOC <cncf-toc@...>, Robert Roeser <robert@...>
Subject: Re: [cncf-toc] RSocket Followup (post TOC meeting)
Colin, your feedback is essential, please do share
Rsocket team, key questions for me are:
- what are main differences/USPs Vs prior art (nats, grpc, 0mq)
- is rsocket more of a lib or a "product'
toggle quoted message
Show quoted text
On Tue, 7 Aug 2018, 17:04 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
|
|
|
How much interoperability testing have you done? Especially in the multi hop multi implementation cases
On Wed, 8 Aug 2018, 22:08 Robert Roeser, < robert@...> wrote:
+stevegury@...
Hi,
Here’s answers to your questions below. Please reach out to Ben Hale, Steve Gury, or myself if you have additional questions
Thanks,
Robert Roeser
Rsocket team, key questions for me are:
- what are main differences/USPs Vs prior art (nats, grpc, 0mq)
- RSocket is essentially distributed RxJava or ReactiveStreams
- RSocket client and server both have a requester and responder. This means that either side of an RSocket connection can initiate a stream. This lets you do interesting things like have
a mobile device connect to a microservice, and then allow the server to make calls directly to the mobile device - as if the mobile device was a server. The mobile device could serve a stream of GPS coordinates, log data, etc.
- RSocket complements ReactiveStreams - ReactiveStreams abstracts asynchrony within a binary boundary (threads, etc) and RSocket abstracts this across a binary boundary (network calls)
- RSocket abstracts the transport from the developer - an application written with RSocket supports whatever transports are implemented.
- The transport abstraction lets you pick a transport appropriate to your environmental constraints. For instance, if you're working with a web browser you can use WebSocket and if you're
in a data center you can use something with higher throughput like Aeron UDP protocol. The developer would not need to change their application logic, just replace the transport RSocket is using.
- Support for ReactiveStreams request n style flow control across a binary boundary
- Request n works by a stream consumer sending the producer the number of items it wants to consume. In RSocket it receives REQUEST_N frame with a number indicating how many items to produce.
- This application level back-pressure is composeable across services
- Optional Leasing support - applications send other applications leases in the form of X requests can be sent of the next Y seconds. Load balancers can use this information to direct traffic
to other services that have capacity.
- Leasing and Back-pressure can obviate the need for additional circuit breakers and rate limiters
- RSocket cancellations are propagated up and down across chains of services - and because ReactiveStreams is lazy this can cancel work before it has started - this is beneficial in error
conditions because it will be prevent extra/wasteful processing.
- Each RSocket connection is a bidirectional stream that arbitrages flow control between transport back-pressure and application back-pressure
- All interactions are modeled as asynchronous streams with optimizations for the different interaction models
- Request/reply - bi-directional stream of one to one
- Fire/Forget - unidirectional stream of one
- Request/Stream - bidirectional stream of one to many
- Request/Channel - bidirectional stream of many to many
- RSocket supports metadata push which you can use to push metadata associated with a connection.
- RSocket can support many thousands of concurrent streams on a single host
- Resumability is handled at the protocol/implementation level, so while this is possible today, the protocol removes it as an application concern. For instance, this lets a developer
work with a flappy network connection as if it's a reliable one. This is particularly useful for mobile developers. This lets you keep your subscriptions active and then RSocket sends missing data when a connection is reestablished.
- gRPC is a RPC on HTTP/2 and I believe was created to leverage existing infrastructure. gRPC's spec is a collection of headers and URLs- in its current implementation it requires something
like HTTP/2 vs RSocket which is a binary framed protocol and can send it over any bi-directional connection. RSocket works in a browser whereas gRPC needs a bridge. You could use RSocket as a layer to building something like gRPC that could run over multiple
layers, rather than being tied to HTTP/2
- NATs is a message broker and a product. NATs requires an external broker, is text based. RSocket is library you would include in your application. You would use RSocket to build something
like NATs
- 0mq is similar in some requests, but IMO the RSocket protocol is simpler than 0mq. Messages in 0mq are blobs, and RSocket payloads have the concept of data and metadata each with their
own mime-type. 0mq is intended to model a message broker vs RSocket which is "distributed RxJava". 0mq doesn't work in a web browser whereas RSocket does.
- is rsocket more of a lib or a "product'
RSocket is a library for network communication like `javax.net` or gRPC. Applications are built upon it, but since it does not _require_ an intermediate broker, there's no product required.
An intermediate broker _can_ be useful and be a product, but this is a transparent addition that is not required by RSocket.
- what's the Go story?
We need to implement a version in Go. We have talked with various parties and there is interest in it. It is not the various RSocket teams core competency, but there is nothing stopping
an implementation from being made as either wrapping the C++ library, or writing a pure golang implementation. We would be happy to help with its implementation.
From:
Alexis Richardson <alexis@...>
Date: Tuesday, August 7, 2018 at 9:14 AM
To: Chris Aniszczyk <caniszczyk@...>
Cc: Ben Hale <bhale@...>, CNCF TOC <cncf-toc@...>, Robert Roeser <robert@...>
Subject: Re: [cncf-toc] RSocket Followup (post TOC meeting)
Colin, your feedback is essential, please do share
Rsocket team, key questions for me are:
- what are main differences/USPs Vs prior art (nats, grpc, 0mq)
- is rsocket more of a lib or a "product'
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
|
|
|
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
|
|
|
|
|
|
Robert Roeser <robert@...>
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
toggle quoted message
Show quoted text
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.
|
|
|
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.
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
toggle quoted message
Show quoted text
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
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.
|
|
|
+1 to a public feature comparison table. In such a table, it will be good to figure out how to do justice to deliberate design choices and the tradeoffs. For example, broker vs no-broker, or choosing to base on top of http/2. Projects have valid reasons to go one way or another, and those considerations are very beneficial for the user to understand.
FYI : I saw a few minor misconceptions for gRPC and I have called out a few that stood out.: - binary - must be wrapped in protobuf. This is not necessary, though offers a convenience. There are other formats (eg: flatbuffers) that support gRPC service generation. - max payload size is confiugrable - full duplex -- not sure what this means. gRPC supports bi directional streams. - IPC is not protobuf only.
|
|
|
On Wed, Aug 8, 2018 at 2:10 PM Robert Roeser < robert@...> wrote:
+stevegury@...
Hi,
Here’s answers to your questions below. Please reach out to Ben Hale, Steve Gury, or myself if you have additional questions
Thanks,
Robert Roeser
Rsocket team, key questions for me are:
- what are main differences/USPs Vs prior art (nats, grpc, 0mq)
- RSocket is essentially distributed RxJava or ReactiveStreams
- RSocket client and server both have a requester and responder. This means that either side of an RSocket connection can initiate a stream. This lets you do interesting things like have
a mobile device connect to a microservice, and then allow the server to make calls directly to the mobile device - as if the mobile device was a server. The mobile device could serve a stream of GPS coordinates, log data, etc.
Is mobile the primary use case today?
- RSocket complements ReactiveStreams - ReactiveStreams abstracts asynchrony within a binary boundary (threads, etc) and RSocket abstracts this across a binary boundary (network calls)
- RSocket abstracts the transport from the developer - an application written with RSocket supports whatever transports are implemented.
- The transport abstraction lets you pick a transport appropriate to your environmental constraints. For instance, if you're working with a web browser you can use WebSocket and if you're
in a data center you can use something with higher throughput like Aeron UDP protocol. The developer would not need to change their application logic, just replace the transport RSocket is using.
- Support for ReactiveStreams request n style flow control across a binary boundary
- Request n works by a stream consumer sending the producer the number of items it wants to consume. In RSocket it receives REQUEST_N frame with a number indicating how many items to produce.
- This application level back-pressure is composeable across services
- Optional Leasing support - applications send other applications leases in the form of X requests can be sent of the next Y seconds. Load balancers can use this information to direct traffic
to other services that have capacity.
Rsocket uses client-slide load balancing to achieve this?
- Leasing and Back-pressure can obviate the need for additional circuit breakers and rate limiters
- RSocket cancellations are propagated up and down across chains of services - and because ReactiveStreams is lazy this can cancel work before it has started - this is beneficial in error
conditions because it will be prevent extra/wasteful processing.
OOC, how much work does cancellation save in practice? Presumably it mostly applies to requests that haven't yet been picked up by their consumers.
- Each RSocket connection is a bidirectional stream that arbitrages flow control between transport back-pressure and application back-pressure
- All interactions are modeled as asynchronous streams with optimizations for the different interaction models
- Request/reply - bi-directional stream of one to one
- Fire/Forget - unidirectional stream of one
- Request/Stream - bidirectional stream of one to many
- Request/Channel - bidirectional stream of many to many
- RSocket supports metadata push which you can use to push metadata associated with a connection.
- RSocket can support many thousands of concurrent streams on a single host
- Resumability is handled at the protocol/implementation level, so while this is possible today, the protocol removes it as an application concern. For instance, this lets a developer
work with a flappy network connection as if it's a reliable one. This is particularly useful for mobile developers. This lets you keep your subscriptions active and then RSocket sends missing data when a connection is reestablished.
- gRPC is a RPC on HTTP/2 and I believe was created to leverage existing infrastructure. gRPC's spec is a collection of headers and URLs- in its current implementation it requires something
like HTTP/2 vs RSocket which is a binary framed protocol and can send it over any bi-directional connection. RSocket works in a browser whereas gRPC needs a bridge. You could use RSocket as a layer to building something like gRPC that could run over multiple
layers, rather than being tied to HTTP/2
- NATs is a message broker and a product. NATs requires an external broker, is text based. RSocket is library you would include in your application. You would use RSocket to build something
like NATs
- 0mq is similar in some requests, but IMO the RSocket protocol is simpler than 0mq. Messages in 0mq are blobs, and RSocket payloads have the concept of data and metadata each with their
own mime-type. 0mq is intended to model a message broker vs RSocket which is "distributed RxJava". 0mq doesn't work in a web browser whereas RSocket does.
- is rsocket more of a lib or a "product'
RSocket is a library for network communication like `javax.net` or gRPC. Applications are built upon it, but since it does not _require_ an intermediate broker, there's no product required.
An intermediate broker _can_ be useful and be a product, but this is a transparent addition that is not required by RSocket.
- what's the Go story?
We need to implement a version in Go. We have talked with various parties and there is interest in it. It is not the various RSocket teams core competency, but there is nothing stopping
an implementation from being made as either wrapping the C++ library, or writing a pure golang implementation. We would be happy to help with its implementation.
From:
Alexis Richardson <alexis@...>
Date: Tuesday, August 7, 2018 at 9:14 AM
To: Chris Aniszczyk <caniszczyk@...>
Cc: Ben Hale <bhale@...>, CNCF TOC <cncf-toc@...>, Robert Roeser <robert@...>
Subject: Re: [cncf-toc] RSocket Followup (post TOC meeting)
Colin, your feedback is essential, please do share
Rsocket team, key questions for me are:
- what are main differences/USPs Vs prior art (nats, grpc, 0mq)
- is rsocket more of a lib or a "product'
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
|
|
|
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? TCP flow control is at the byte level and RSocket is flow control at the message level. It's often easier to reason at the message level when you build applications because you don't have to guess how many bytes a single message is. RSocket arbitrages between transport level flow control, and Reactive Streams semantic. When you have asynchronous applications that don't have thread pools, the back pressure provided by TCP is often broken because the number of bytes in a message doesn't necessarily correspond to how expensive it is to process. You can have a one megabyte message processed swiftly and a one kilobyte message that is expensive. Most people already deal with this application-level flow control problem already using circuit breakers, rate limiters, request throttling and bounded thread pools as you mention. These are all examples of application back pressure but the common limitation is that all cause an error on the client side when capacity is exceeded. Essentially, you can only find out if you need to back off by attempting first and then failing. RSocket eliminates this failing attempt because a client will only request a volume _it_ knows it can handle, and then the server will only send that. This prevents things like retry storms and extra processing while resulting in better tail latency, etc. To illustrate this, imagine you have three services A streaming to B, B streaming to C. Lets also say that they are streaming data at 25% of the capacity of the TCP buffer. C slows down with garbage collection, or expensive to process items. With TCP each buffer has to fill up before A (the root generator) slows down and this only happens after messages have been sent. This leads to cascading failures in services: C is going to get messages it can't handle regardless of the TCP back pressure. The typical way to deal with is add circuit breakers, and rate limiting that create errors when they reach a certain capacity. With RSocket you don't need circuit breakers; instead C stops sending requestN requests to B, and B stops sending requestN's A. Everything slows down to the rate that C can handle, and this happens uniquely and individually for each end-client's performance. Besides application safety, Reactive Stream requestN semantics make it easier for the developer to create applications that scroll over data, page over data, or take a finite amount of data from a stream. It's difficult to reason about how many bytes 8 'user profiles' are, but it's very easy to ask for 8. -Ben
|
|
|
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.
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?
TCP flow control is at the byte level and RSocket is flow control at the message level. It's often easier to reason at the message level when you build applications because you don't have to guess how many bytes a single message is. RSocket arbitrages between transport level flow control, and Reactive Streams semantic.
When you have asynchronous applications that don't have thread pools, the back pressure provided by TCP is often broken because the number of bytes in a message doesn't necessarily correspond to how expensive it is to process. You can have a one megabyte message processed swiftly and a one kilobyte message that is expensive. Most people already deal with this application-level flow control problem already using circuit breakers, rate limiters, request throttling and bounded thread pools as you mention. These are all examples of application back pressure but the common limitation is that all cause an error on the client side when capacity is exceeded. Essentially, you can only find out if you need to back off by attempting first and then failing. RSocket eliminates this failing attempt because a client will only request a volume _it_ knows it can handle, and then the server will only send that. This prevents things like retry storms and extra processing while resulting in better tail latency, etc.
To illustrate this, imagine you have three services A streaming to B, B streaming to C. Lets also say that they are streaming data at 25% of the capacity of the TCP buffer. C slows down with garbage collection, or expensive to process items. With TCP each buffer has to fill up before A (the root generator) slows down and this only happens after messages have been sent. This leads to cascading failures in services: C is going to get messages it can't handle regardless of the TCP back pressure. The typical way to deal with is add circuit breakers, and rate limiting that create errors when they reach a certain capacity. With RSocket you don't need circuit breakers; instead C stops sending requestN requests to B, and B stops sending requestN's A. Everything slows down to the rate that C can handle, and this happens uniquely and individually for each end-client's performance.
Besides application safety, Reactive Stream requestN semantics make it easier for the developer to create applications that scroll over data, page over data, or take a finite amount of data from a stream. It's difficult to reason about how many bytes 8 'user profiles' are, but it's very easy to ask for 8.
-Ben
|
|
|
Is mobile the primary use case today? RSocket’s primary use-case is distributed systems communication. I mentioned the above example as it’s difficult to do that today and you usually need additional components like Socket.io, long-polling, etc, where as with RSocket it is natural. Resumabilty was added for the mobile use-case and today's implementation is warm resumablity where theserver side hasn’t timed out the subscriptions and flushed them. There has been talk to do cold resumabilty where you could have streams that are able to resume when there isn’t a active subscription on the producing side. Rsocket uses client-slide load balancing to achieve this?
https://github.com/rsocket/rsocket-java/tree/1.0.x/rsocket-load-balancer You could do it with client-client load balancer, or a middle-ware load-balancer that understands RSocket. Steve Gury can provide more context about load-balancing on a large scale. OOC, how much work does cancellation save in practice? Presumably it mostly applies to requests that haven't yet been picked up by their consumers. Depending on what you are doing, it could be lots of work. RSocket provides Reactive Stream semantics across a process boundary. In Reactive Streams there are three ways to terminate a stream: it completes, it errors, or you cancel it. All streams (including request/response) support cancellation to allow efficient cleanup of responder resources. This is essential with interaction models such as streams and subscriptions - you need it to cleanly signal to stop streaming data where the stream doesn’t complete or error. An example how how this works could be a stream of data that has 1,000,000 items, and you want to take a 100 items from it. With ReactiveStreams you can ask for 100 items, and then cancel when you receive them. Before RSocket you could only do this in the same process. With RSocket you can do this between services, even across multiple services it you want (A->B->C……->N). If you use a ReactiveStreams library like RXJava, Reactor-core, Akka-streams, Yarl, etc. all this happens automatically. You basically need to write something like this: ``` Payload p = null; requestStream(p) .limitRequest(100) .subscribe(doSomethingInteresting()); ``` The developer doesn’t need to concern them with back pressure or cancellation but the implementation will use this to create the behavior the developer wants. -Ben
|
|
|
Go, java, js and c++ would be a convincing portfolio, if interop worked.
On Fri, 10 Aug 2018, 20:56 Ben Hale, < bhale@...> wrote: In addition, Pivotal's interest in RSocket extends beyond the Java implementation and we're specifically interested in JavaScript and Go. For us to be comfortable, we'd ensure reliable interoperability before we took anything to market with those implementations. Contributing to the TCK and extensive cross implementation testing would be efforts we'd contribute to.
-Ben
> On Aug 10, 2018, at 12:54, Robert Roeser <robert@...> wrote:
>
> Hi Alexis,
>
> How much interoperability testing have you done? Especially in the multi hop multi implementation cases
> There are internal tests using RSocket with the different implementations and they interoperate – have done tests where C++ calls Java which calls a service in a browser tab (browser acts like microservice), etc. The spec has been fleshed as people worked on the different versions. The TCK is on the road map to be worked on again, we just need to figure out where to host these tests in public.
>
> Cheers,
> Robert
>
>
> From: Alexis Richardson <alexis@...>
> Date: Wednesday, August 8, 2018 at 2:41 PM
> To: Robert Roeser <robert@...>
> Cc: Ben Hale <bhale@...>, CNCF TOC <cncf-toc@...>, Chris Aniszczyk <caniszczyk@...>, "stevegury@..." <stevegury@...>
> Subject: Re: [cncf-toc] RSocket Followup (post TOC meeting)
>
> How much interoperability testing have you done? Especially in the multi hop multi implementation cases
>
> On Wed, 8 Aug 2018, 22:08 Robert Roeser, <robert@...> wrote:
> +stevegury@...
>
> Hi,
>
> Here’s answers to your questions below. Please reach out to Ben Hale, Steve Gury, or myself if you have additional questions
>
> Thanks,
> Robert Roeser
>
> Rsocket team, key questions for me are:
>
> - what are main differences/USPs Vs prior art (nats, grpc, 0mq)
> - RSocket is essentially distributed RxJava or ReactiveStreams
>
> - RSocket client and server both have a requester and responder. This means that either side of an RSocket connection can initiate a stream. This lets you do interesting things like have a mobile device connect to a microservice, and then allow the server to make calls directly to the mobile device - as if the mobile device was a server. The mobile device could serve a stream of GPS coordinates, log data, etc.
>
> - RSocket complements ReactiveStreams - ReactiveStreams abstracts asynchrony within a binary boundary (threads, etc) and RSocket abstracts this across a binary boundary (network calls)
> - RSocket abstracts the transport from the developer - an application written with RSocket supports whatever transports are implemented.
> - The transport abstraction lets you pick a transport appropriate to your environmental constraints. For instance, if you're working with a web browser you can use WebSocket and if you're in a data center you can use something with higher throughput like Aeron UDP protocol. The developer would not need to change their application logic, just replace the transport RSocket is using.
> - Support for ReactiveStreams request n style flow control across a binary boundary
> - Request n works by a stream consumer sending the producer the number of items it wants to consume. In RSocket it receives REQUEST_N frame with a number indicating how many items to produce.
> - This application level back-pressure is composeable across services
> - Optional Leasing support - applications send other applications leases in the form of X requests can be sent of the next Y seconds. Load balancers can use this information to direct traffic to other services that have capacity.
> - Leasing and Back-pressure can obviate the need for additional circuit breakers and rate limiters
>
> - RSocket cancellations are propagated up and down across chains of services - and because ReactiveStreams is lazy this can cancel work before it has started - this is beneficial in error conditions because it will be prevent extra/wasteful processing.
>
> - Each RSocket connection is a bidirectional stream that arbitrages flow control between transport back-pressure and application back-pressure
> - All interactions are modeled as asynchronous streams with optimizations for the different interaction models
> - Request/reply - bi-directional stream of one to one
> - Fire/Forget - unidirectional stream of one
> - Request/Stream - bidirectional stream of one to many
> - Request/Channel - bidirectional stream of many to many
>
> - RSocket supports metadata push which you can use to push metadata associated with a connection.
>
> - RSocket can support many thousands of concurrent streams on a single host
>
> - Resumability is handled at the protocol/implementation level, so while this is possible today, the protocol removes it as an application concern. For instance, this lets a developer work with a flappy network connection as if it's a reliable one. This is particularly useful for mobile developers. This lets you keep your subscriptions active and then RSocket sends missing data when a connection is reestablished.
>
> - gRPC is a RPC on HTTP/2 and I believe was created to leverage existing infrastructure. gRPC's spec is a collection of headers and URLs- in its current implementation it requires something like HTTP/2 vs RSocket which is a binary framed protocol and can send it over any bi-directional connection. RSocket works in a browser whereas gRPC needs a bridge. You could use RSocket as a layer to building something like gRPC that could run over multiple layers, rather than being tied to HTTP/2
>
> - NATs is a message broker and a product. NATs requires an external broker, is text based. RSocket is library you would include in your application. You would use RSocket to build something like NATs
>
> - 0mq is similar in some requests, but IMO the RSocket protocol is simpler than 0mq. Messages in 0mq are blobs, and RSocket payloads have the concept of data and metadata each with their own mime-type. 0mq is intended to model a message broker vs RSocket which is "distributed RxJava". 0mq doesn't work in a web browser whereas RSocket does.
>
> - is rsocket more of a lib or a "product'
> RSocket is a library for network communication like `javax.net` or gRPC. Applications are built upon it, but since it does not _require_ an intermediate broker, there's no product required. An intermediate broker _can_ be useful and be a product, but this is a transparent addition that is not required by RSocket.
>
> - what's the Go story?
> We need to implement a version in Go. We have talked with various parties and there is interest in it. It is not the various RSocket teams core competency, but there is nothing stopping an implementation from being made as either wrapping the C++ library, or writing a pure golang implementation. We would be happy to help with its implementation.
>
> From: Alexis Richardson <alexis@...>
> Date: Tuesday, August 7, 2018 at 9:14 AM
> To: Chris Aniszczyk <caniszczyk@...>
> Cc: Ben Hale <bhale@...>, CNCF TOC <cncf-toc@...>, Robert Roeser <robert@...>
> Subject: Re: [cncf-toc] RSocket Followup (post TOC meeting)
>
> Colin, your feedback is essential, please do share
>
> Rsocket team, key questions for me are:
>
> - what are main differences/USPs Vs prior art (nats, grpc, 0mq)
> - is rsocket more of a lib or a "product'
> - what's the Go story?
>
>
> On Tue, 7 Aug 2018, 17:04 Chris Aniszczyk, <caniszczyk@...> wrote:
> https://github.com/rsocket
>
> 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
|
|
|
Robert Roeser <robert@...>
Hi Alexis,
How much interoperability testing have you done? Especially in the multi hop multi implementation cases
There are internal tests using RSocket with the different implementations and they interoperate – have done tests where C++ calls Java which calls a service in a browser tab (browser acts
like microservice), etc. The spec has been fleshed as people worked on the different versions. The TCK is on the road map to be worked on again, we just need to figure out where to host these tests in public.
Cheers,
Robert
From:
Alexis Richardson <alexis@...>
Date: Wednesday, August 8, 2018 at 2:41 PM
To: Robert Roeser <robert@...>
Cc: Ben Hale <bhale@...>, CNCF TOC <cncf-toc@...>, Chris Aniszczyk <caniszczyk@...>, "stevegury@..." <stevegury@...>
Subject: Re: [cncf-toc] RSocket Followup (post TOC meeting)
How much interoperability testing have you done? Especially in the multi hop multi implementation cases
toggle quoted message
Show quoted text
On Wed, 8 Aug 2018, 22:08 Robert Roeser, < robert@...> wrote:
+stevegury@...
Hi,
Here’s answers to your questions below. Please reach out to Ben Hale, Steve Gury, or myself if you have additional questions
Thanks,
Robert Roeser
Rsocket team, key questions for me are:
- what are main differences/USPs Vs prior art (nats, grpc, 0mq)
- RSocket is essentially distributed RxJava or ReactiveStreams
- RSocket client and server both have a requester and responder. This means that either side of an RSocket connection can initiate
a stream. This lets you do interesting things like have a mobile device connect to a microservice, and then allow the server to make calls directly to the mobile device - as if the mobile device was a server. The mobile device could serve a stream of GPS coordinates,
log data, etc.
- RSocket complements ReactiveStreams - ReactiveStreams abstracts asynchrony within a binary boundary (threads, etc) and
RSocket abstracts this across a binary boundary (network calls)
- RSocket abstracts the transport from the developer - an application written with RSocket supports whatever transports are implemented.
- The transport abstraction lets you pick a transport appropriate to your environmental constraints. For instance, if you're
working with a web browser you can use WebSocket and if you're in a data center you can use something with higher throughput like Aeron UDP protocol. The developer would not need to change their application logic, just replace the transport RSocket is using.
- Support for ReactiveStreams request n style flow control across a binary boundary
- Request n works by a stream consumer sending the producer the number of items it wants to consume. In RSocket it receives REQUEST_N
frame with a number indicating how many items to produce.
- This application level back-pressure is composeable across services
- Optional Leasing support - applications send other applications leases in the form of X requests can be sent of the next Y seconds.
Load balancers can use this information to direct traffic to other services that have capacity.
- Leasing and Back-pressure can obviate the need for additional circuit breakers and rate limiters
- RSocket cancellations are propagated up and down across chains of services - and because ReactiveStreams is lazy this can cancel
work before it has started - this is beneficial in error conditions because it will be prevent extra/wasteful processing.
- Each RSocket connection is a bidirectional stream that arbitrages flow control between transport back-pressure and application
back-pressure
- All interactions are modeled as asynchronous streams with optimizations for the different interaction models
- Request/reply - bi-directional stream of one to one
- Fire/Forget - unidirectional stream of one
- Request/Stream - bidirectional stream of one to many
- Request/Channel - bidirectional stream of many to many
- RSocket supports metadata push which you can use to push metadata associated with a connection.
- RSocket can support many thousands of concurrent streams on a single host
- Resumability is handled at the protocol/implementation level, so while this is possible today, the protocol removes it as an
application concern. For instance, this lets a developer work with a flappy network connection as if it's a reliable one. This is particularly useful for mobile developers. This lets you keep your subscriptions active and then RSocket sends missing data when
a connection is reestablished.
- gRPC is a RPC on HTTP/2 and I believe was created to leverage existing infrastructure. gRPC's spec is a collection of headers
and URLs- in its current implementation it requires something like HTTP/2 vs RSocket which is a binary framed protocol and can send it over any bi-directional connection. RSocket works in a browser whereas gRPC needs a bridge. You could use RSocket as a layer
to building something like gRPC that could run over multiple layers, rather than being tied to HTTP/2
- NATs is a message broker and a product. NATs requires an external broker, is text based. RSocket is library you would include
in your application. You would use RSocket to build something like NATs
- 0mq is similar in some requests, but IMO the RSocket protocol is simpler than 0mq. Messages in 0mq are blobs, and RSocket payloads
have the concept of data and metadata each with their own mime-type. 0mq is intended to model a message broker vs RSocket which is "distributed RxJava". 0mq doesn't work in a web browser whereas RSocket does.
- is rsocket more of a lib or a "product'
RSocket is a library for network communication like `javax.net` or gRPC. Applications
are built upon it, but since it does not _require_ an intermediate broker, there's no product required. An intermediate broker _can_ be useful and be a product, but this is a transparent addition that is not required by RSocket.
- what's the Go story?
We need to implement a version in Go. We have talked with various parties and there is interest in it. It is not the various RSocket
teams core competency, but there is nothing stopping an implementation from being made as either wrapping the C++ library, or writing a pure golang implementation. We would be happy to help with its implementation.
From:
Alexis Richardson <alexis@...>
Date: Tuesday, August 7, 2018 at 9:14 AM
To: Chris Aniszczyk <caniszczyk@...>
Cc: Ben Hale <bhale@...>, CNCF TOC <cncf-toc@...>, Robert Roeser <robert@...>
Subject: Re: [cncf-toc] RSocket Followup (post TOC meeting)
Colin, your feedback is essential, please do share
Rsocket team, key questions for me are:
- what are main differences/USPs Vs prior art (nats, grpc, 0mq)
- is rsocket more of a lib or a "product'
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
|
|
|
In addition, Pivotal's interest in RSocket extends beyond the Java implementation and we're specifically interested in JavaScript and Go. For us to be comfortable, we'd ensure reliable interoperability before we took anything to market with those implementations. Contributing to the TCK and extensive cross implementation testing would be efforts we'd contribute to.
-Ben
toggle quoted message
Show quoted text
On Aug 10, 2018, at 12:54, Robert Roeser <robert@...> wrote:
Hi Alexis,
How much interoperability testing have you done? Especially in the multi hop multi implementation cases
There are internal tests using RSocket with the different implementations and they interoperate – have done tests where C++ calls Java which calls a service in a browser tab (browser acts like microservice), etc. The spec has been fleshed as people worked on the different versions. The TCK is on the road map to be worked on again, we just need to figure out where to host these tests in public.
Cheers,
Robert
From: Alexis Richardson <alexis@...>
Date: Wednesday, August 8, 2018 at 2:41 PM
To: Robert Roeser <robert@...>
Cc: Ben Hale <bhale@...>, CNCF TOC <cncf-toc@...>, Chris Aniszczyk <caniszczyk@...>, "stevegury@..." <stevegury@...>
Subject: Re: [cncf-toc] RSocket Followup (post TOC meeting)
How much interoperability testing have you done? Especially in the multi hop multi implementation cases
On Wed, 8 Aug 2018, 22:08 Robert Roeser, <robert@...> wrote:
+stevegury@...
Hi,
Here’s answers to your questions below. Please reach out to Ben Hale, Steve Gury, or myself if you have additional questions
Thanks,
Robert Roeser
Rsocket team, key questions for me are:
- what are main differences/USPs Vs prior art (nats, grpc, 0mq)
- RSocket is essentially distributed RxJava or ReactiveStreams
- RSocket client and server both have a requester and responder. This means that either side of an RSocket connection can initiate a stream. This lets you do interesting things like have a mobile device connect to a microservice, and then allow the server to make calls directly to the mobile device - as if the mobile device was a server. The mobile device could serve a stream of GPS coordinates, log data, etc.
- RSocket complements ReactiveStreams - ReactiveStreams abstracts asynchrony within a binary boundary (threads, etc) and RSocket abstracts this across a binary boundary (network calls)
- RSocket abstracts the transport from the developer - an application written with RSocket supports whatever transports are implemented.
- The transport abstraction lets you pick a transport appropriate to your environmental constraints. For instance, if you're working with a web browser you can use WebSocket and if you're in a data center you can use something with higher throughput like Aeron UDP protocol. The developer would not need to change their application logic, just replace the transport RSocket is using.
- Support for ReactiveStreams request n style flow control across a binary boundary
- Request n works by a stream consumer sending the producer the number of items it wants to consume. In RSocket it receives REQUEST_N frame with a number indicating how many items to produce.
- This application level back-pressure is composeable across services
- Optional Leasing support - applications send other applications leases in the form of X requests can be sent of the next Y seconds. Load balancers can use this information to direct traffic to other services that have capacity.
- Leasing and Back-pressure can obviate the need for additional circuit breakers and rate limiters
- RSocket cancellations are propagated up and down across chains of services - and because ReactiveStreams is lazy this can cancel work before it has started - this is beneficial in error conditions because it will be prevent extra/wasteful processing.
- Each RSocket connection is a bidirectional stream that arbitrages flow control between transport back-pressure and application back-pressure
- All interactions are modeled as asynchronous streams with optimizations for the different interaction models
- Request/reply - bi-directional stream of one to one
- Fire/Forget - unidirectional stream of one
- Request/Stream - bidirectional stream of one to many
- Request/Channel - bidirectional stream of many to many
- RSocket supports metadata push which you can use to push metadata associated with a connection.
- RSocket can support many thousands of concurrent streams on a single host
- Resumability is handled at the protocol/implementation level, so while this is possible today, the protocol removes it as an application concern. For instance, this lets a developer work with a flappy network connection as if it's a reliable one. This is particularly useful for mobile developers. This lets you keep your subscriptions active and then RSocket sends missing data when a connection is reestablished.
- gRPC is a RPC on HTTP/2 and I believe was created to leverage existing infrastructure. gRPC's spec is a collection of headers and URLs- in its current implementation it requires something like HTTP/2 vs RSocket which is a binary framed protocol and can send it over any bi-directional connection. RSocket works in a browser whereas gRPC needs a bridge. You could use RSocket as a layer to building something like gRPC that could run over multiple layers, rather than being tied to HTTP/2
- NATs is a message broker and a product. NATs requires an external broker, is text based. RSocket is library you would include in your application. You would use RSocket to build something like NATs
- 0mq is similar in some requests, but IMO the RSocket protocol is simpler than 0mq. Messages in 0mq are blobs, and RSocket payloads have the concept of data and metadata each with their own mime-type. 0mq is intended to model a message broker vs RSocket which is "distributed RxJava". 0mq doesn't work in a web browser whereas RSocket does.
- is rsocket more of a lib or a "product'
RSocket is a library for network communication like `javax.net` or gRPC. Applications are built upon it, but since it does not _require_ an intermediate broker, there's no product required. An intermediate broker _can_ be useful and be a product, but this is a transparent addition that is not required by RSocket.
- what's the Go story?
We need to implement a version in Go. We have talked with various parties and there is interest in it. It is not the various RSocket teams core competency, but there is nothing stopping an implementation from being made as either wrapping the C++ library, or writing a pure golang implementation. We would be happy to help with its implementation.
From: Alexis Richardson <alexis@...>
Date: Tuesday, August 7, 2018 at 9:14 AM
To: Chris Aniszczyk <caniszczyk@...>
Cc: Ben Hale <bhale@...>, CNCF TOC <cncf-toc@...>, Robert Roeser <robert@...>
Subject: Re: [cncf-toc] RSocket Followup (post TOC meeting)
Colin, your feedback is essential, please do share
Rsocket team, key questions for me are:
- what are main differences/USPs Vs prior art (nats, grpc, 0mq)
- is rsocket more of a lib or a "product'
- what's the Go story?
On Tue, 7 Aug 2018, 17:04 Chris Aniszczyk, <caniszczyk@...> wrote:
https://github.com/rsocket
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
|
|
|
Timothy Bozarth <tim@...>
I see Kailash CCd me into the thread given Netflix's experience with both RSocket and gRPC.
It should be noted that at this point (as of roughly 6 months ago) all use of RSocket has been completely abandoned at Netflix in favor of gRPC, and the only team that build an app with RSocket chose to rewrite their app leveraging gRPC and the associated components. gRPC has also allowed us to build (and easily integrate) a suite of resilience-oriented tech, such as our Adaptive Concurrency Limiters (https://medium.com/@NetflixTechBlog/performance-under-load-3e6fa9a60581) that solve the retry-storm problem with no additional client-side complexity or configuration.
While I am not best-suited to address statements on the matrix of specific points being discussed, if anyone has questions, I can speak to the many usability/ergonomic, simplicity, community, and development-velocity/productivity related reasons that ultimately led Netflix (both the Platform team, and the users) to choose gRPC as our microservice RPC foundation.
Tim Bozarth Director, Platform @ Netflix
On Thu, Aug 9, 2018 at 10:52 AM, Kailash Sethuraman <hsaliak@...> wrote:
+1 to a public feature comparison table. In such a table, it will be good to figure out how to do justice to deliberate design choices and the tradeoffs. For example, broker vs no-broker, or choosing to base on top of http/2. Projects have valid reasons to go one way or another, and those considerations are very beneficial for the user to understand.
FYI : I saw a few minor misconceptions for gRPC and I have called out a few that stood out.: - binary - must be wrapped in protobuf. This is not necessary, though offers a convenience. There are other formats (eg: flatbuffers) that support gRPC service generation. - max payload size is confiugrable - full duplex -- not sure what this means. gRPC supports bi directional streams. - IPC is not protobuf only.
|
|
|
