Is gRPC (or http2) resumable?

[Mostafa Eweda]

In my use case, always-open gRPC calls / streams are common, where it'd be idea if they can resume between shorts disconnects (going away).

• Q1: Is there a way that a server would know about the caller's client going away?
• The client's RPC calls fail later with an error (e.g. Endpoint failed to read).
• Q2: Can it resume instead? is that configurable?
• Q3: Is there a way to learn that the client / server went away in the API? heartbeat / ping? -- `channel.watchConnectivityState` takes too long and only works in the client.
• HTTP2 (the heart of gRPC) doesn't seem to have resumability in mind, while https://github.com/rsocket/rsocket/ does.
  Q4: Could gRPC potentially live on various underlying wire protocols, or will it be always committed to http2 (https://developers.googleblog.com/2015/02/introducing-grpc-new-open-source-http2.html)?
• Q5: [grpc-node] Is there a plan for a server impl in Node as well?
• Q6: [grpc-node] Any reason to use Node 8.4+ `http2` module over using the `http2` npm package to make it work on all node versions?

Thanks,

Mostafa.

[Carl Mastrangelo]

Answers inline

On Tuesday, October 3, 2017 at 4:45:55 PM UTC-7, Mostafa Eweda wrote:

In my use case, always-open gRPC calls / streams are common, where it'd be idea if they can resume between shorts disconnects (going away).

• Q1: Is there a way that a server would know about the caller's client going away?

No, but your client can send a "going away" message just before disconnecting.  gRPC is very much a message based protocol.

 

• The client's RPC calls fail later with an error (e.g. Endpoint failed to read).
• Q2: Can it resume instead? is that configurable?
• Q3: Is there a way to learn that the client / server went away in the API? heartbeat / ping? -- `channel.watchConnectivityState` takes too long and only works in the client.
• HTTP2 (the heart of gRPC) doesn't seem to have resumability in mind, while https://github.com/rsocket/rsocket/ does.
  

For the HTTP/2 part: it should be resumable when the QUIC transport is introduced.  That includes an id that allows connection reuse that is independent of the 4-tuple typically used to identify connections.

 

• Q4: Could gRPC potentially live on various underlying wire protocols, or will it be always committed to http2 (https://developers.googleblog.com/2015/02/introducing-grpc-new-open-source-http2.html)?

It will always have HTTP semantics (as in rfc 7230), but it isn't tied to HTTP/2.

[Michael Lumish]

We do plan to implement a pure JavaScript server, but we're prioritizing the client and there is a lot of client work to do first.

Regarding the npm "http2" module, its own README on GitHub says that it is deprecated in favor of the new built in http2 module. In addition, that module did not provide the fine-grained protocol control that we use in grpc.

--
You received this message because you are subscribed to the Google Groups "grpc.io" group.
To unsubscribe from this group and stop receiving emails from it, send an email to grpc-io+u...@googlegroups.com.
To post to this group, send email to grp...@googlegroups.com.
Visit this group at https://groups.google.com/group/grpc-io.
To view this discussion on the web visit https://groups.google.com/d/msgid/grpc-io/8a2ad5ff-de0d-4be8-9b0c-20ae87e446c9%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.