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