You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Our current gRPC layer only supports unary RPCs, while some of our current communication patterns, such as object location subscriptions, actor method calls, and within-lease task submissions, and future communication patterns, such as a non-Redis GCS-based pub/sub, are best suited to streaming RPCs. Streaming RPCs take full advantage of HTTP/2, streaming requests and/or responses within an existing HTTP/2 request/response, ridding ourselves of the overhead of e.g. creating a new HTTP/2 request for each unary call. Moreover, we have ordering guarantees within a single RPC, which saves us from RPC reordering issues that we may encounter when using unary RPCs that would normally have to be handled in the application-level protocol.
The current gRPC layer is completion queue based; we can either extend the completion queue state machines and client/server calls to support streaming RPCs, or we can try out the experimental (and soon to be stable) callback API. I'm leaning towards trying the latter first.
The text was updated successfully, but these errors were encountered:
Our current gRPC layer only supports unary RPCs, while some of our current communication patterns, such as object location subscriptions, actor method calls, and within-lease task submissions, and future communication patterns, such as a non-Redis GCS-based pub/sub, are best suited to streaming RPCs. Streaming RPCs take full advantage of HTTP/2, streaming requests and/or responses within an existing HTTP/2 request/response, ridding ourselves of the overhead of e.g. creating a new HTTP/2 request for each unary call. Moreover, we have ordering guarantees within a single RPC, which saves us from RPC reordering issues that we may encounter when using unary RPCs that would normally have to be handled in the application-level protocol.
The current gRPC layer is completion queue based; we can either extend the completion queue state machines and client/server calls to support streaming RPCs, or we can try out the experimental (and soon to be stable) callback API. I'm leaning towards trying the latter first.
The text was updated successfully, but these errors were encountered: