Callback to clients

[Felipe Farinon]

Is there any native support in the library for clients to receive messages from the server that aren't requested for? I have to solve a scenario where the clients have to receive messages from the server without poling the server.

Thank you.

[Josh Humphries]

Technically, the data from the server must be "requested". Streams are initiated by the clients, never by the server.

However, this could be approximated with an RPC method that has a streaming response. Each client sends this RPC once on connect (could be a unary empty request message). Servers can then push to the client via the response stream, which is kept open indefinitely until disconnect. If servers can push various types of data to the client, that could be modeled using a oneof in the protobuf response type.

----

Josh Humphries

Manager, Shared Systems  |  Platform Engineering

Atlanta, GA  |  678-400-4867

Square (www.squareup.com)

On Mon, Aug 10, 2015 at 2:27 PM, Felipe Farinon <felipe....@gmail.com> wrote:

Is there any native support in the library for clients to receive messages from the server that aren't requested for? I have to solve a scenario where the clients have to receive messages from the server without poling the server.

Thank you.

--
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.
To view this discussion on the web visit https://groups.google.com/d/msgid/grpc-io/d8f4add6-1bd4-453c-8010-95edba84a8c2%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Felipe Goron Farinon]

Sounds like a workaround, I wonder if this scenario is commonly used.

The protocol guarantees that the stream will live until the client or the server explicitly disconnects it?

Is there any heartbeat mechanism that disconnects the stream if the connection is broken?

[Josh Humphries]

Yes, the stream is maintained until the client cancels it or the server explicitly finishes it (successfully or exceptionally). The stream is also broken implicitly if a partition causes a disconnect.

In the Java runtime, ChannelImpl includes a ping() method which can be used to verify the connection is in tact. You could periodically issue pings. When the stream completes, either normally (like if server closes stream on shutdown) or exceptionally (e.g. connection breaks), the client can just re-issue the RPC, which will create a new stream on a new underlying connection.

There is also a simple health-check service that will be available (https://github.com/grpc/grpc/pull/2806), which can be registered in both clients and servers and allow you to use a separate RPC to poll the status of the server.

----

Josh Humphries

Manager, Shared Systems  |  Platform Engineering

Atlanta, GA  |  678-400-4867

Square (www.squareup.com)

[Nicolas Noble]

Think of it more as a subscription system. If you're doing, say, an IRC-like chat system, your client will subscribe to incoming message events from the server, keeping the stream open for as long as the connection exists. Joining a channel is another subscription. It's probably even smarter to do one subscription per event class, if they don't need to be related to each other, because then the various messages can mux with each other within the HTTP2 protocol. In the case of the fictive IRC client/server, you could have one subscription for incoming private messages, one subscription for server notifications of problems, one subscription for walls, etc.

To view this discussion on the web visit https://groups.google.com/d/msgid/grpc-io/CAHJZN-sphv62rSNL3JDMTWz%3DwZ83zW8xj69Rn0XJP_o6v%3DCMqw%40mail.gmail.com.