gRPC - server client communication

[Mosca, Federico]

Hi,

we are trying to use gRPC in the following configuration:

 

-          a test_runner the initiate both client and server

-          once up, client and server should exchange messages in a bidirectional way

-          with the server that start to send messages

-          at the end of the tests both client and server are shutting down

 

Is it possible to create something similar with gRPC?

 

I saw something similar in this paper http://platformlab.stanford.edu/Seminar%20Talks/gRPC.pdf

 

We are using python, is there any example or documentation to explain how to do if it is possible? (also in another languages is fine).

 

Thanks

[Nathaniel Manista]

Pleased to meet you, Federico.

On Thu, Jul 28, 2016 at 5:05 AM, Mosca, Federico <federic...@here.com> wrote:

we are trying to use gRPC in the following configuration: 

-          a test_runner the initiate both client and server

-          once up, client and server should exchange messages in a bidirectional way

-          with the server that start to send messages

-          at the end of the tests both client and server are shutting down

Is it possible to create something similar with gRPC?

This exact scenario is achievable with gRPC.

I saw something similar in this paper http://platformlab.stanford.edu/Seminar%20Talks/gRPC.pdf

 

We are using python, is there any example or documentation to explain how to do if it is possible?

Have you yet seen the documentation at grpc.io (one note on timing: we're preparing for our 1.0.0 release and some of this documentation has not yet been updated)? Have you yet seen the examples in our repository at examples/python (be sure to use grpcio 1.0.0rc1 or later when working through these examples)?

(also in another languages is fine).

Other languages are similarly set up with documentation and examples.

-N

[Mosca, Federico]

Hi Nathaniel,

yes I upgraded to latest python version of grpc (1.0.0rc1) but in all the examples that I checked the scenario is the following:

- start server

- start client

- client send message to server that reply (https://github.com/grpc/grpc/blob/846768c12ff03ea69073c9373ef211ef478c53d6/examples/python/helloworld/greeter_client.py#L42)

I need to create a scenario where is the server that send message to client once both are up and running (as first that initiate the communication).

Maybe I'm missing something in the example/documentation, could you please point me where to look?

Thanks 

---

From: Nathaniel Manista <nath...@google.com>
Sent: Thursday, July 28, 2016 6:52:58 PM
To: Mosca, Federico
Cc: grp...@googlegroups.com
Subject: Re: [grpc-io] gRPC - server client communication

 

[Nathaniel Manista]

On Thu, Jul 28, 2016 at 12:15 PM, Mosca, Federico <federic...@here.com> wrote:

yes I upgraded to latest python version of grpc (1.0.0rc1) but in all the examples that I checked the scenario is the following:

- start server

- start client

- client send message to server that reply (https://github.com/grpc/grpc/blob/846768c12ff03ea69073c9373ef211ef478c53d6/examples/python/helloworld/greeter_client.py#L42)

I need to create a scenario where is the server that send message to client once both are up and running (as first that initiate the communication).

Maybe I'm missing something in the example/documentation, could you please point me where to look?

I apologize; it had escaped me that our examples don't quite illustrate your intended use. Two important things that gRPC does require are that the client has to initiate communication with the server (by establishing a channel) and that the client has to initiate the bidirectionally-streaming RPC. What is not required is that the client send the first message. It's perfectly fine for the server to send the first message. It's perfectly fine for the server to send all its messages before the client sends any. It's perfectly fine for the server to send all its messages and for the client to never send a single message.

-N

[Mosca, Federico]

Hi, so do you suggest to do this:

client.py

import grpc
import generated.bidirectional_pb2 as bid

 

def run():
    channel = grpc.insecure_channel('localhost:50051')
    stub = bid.SpeakStub(channel)

if __name__ == '__main__':
  run()

 

server.py

def serve():
    server = grpc.server(futures.ThreadPoolExecutor(max_workers=10))
    bid.add_SpeakServicer_to_server(bid.SpeakServicer(),server)
    server.add_insecure_port('[::]:50051')
    server.start()
    print "[SERVER] start at 50051"
    try:
        while True:
            time.sleep(_ONE_DAY_IN_SECONDS)
    except KeyboardInterrupt:
        server.stop(0)

if __name__ == '__main__':
    serve()

but I don’t get where I should implement the servicer SpeakServicer(bid.BetaSpeakServicer) and how to invoke it for be that the server send the message to the client.

Where the proto file is

service Speak {

    rpc Message(stream Request) returns (stream Response){}

}

Can you help me?

Thanks

 

From: Nathaniel Manista <nath...@google.com>
Date: Thursday, July 28, 2016 at 9:43 PM
To: "Mosca, Federico" <federic...@here.com>
Cc: "grp...@googlegroups.com" <grp...@googlegroups.com>
Subject: Re: [grpc-io] gRPC - server client communication

 

On Thu, Jul 28, 2016 at 12:15 PM, Mosca, Federico <federic...@here.com> wrote:

[Nathaniel Manista]

On Fri, Jul 29, 2016 at 5:24 AM, Mosca, Federico <federic...@here.com> wrote:

Hi, so do you suggest to do this:

client.py

import grpc
import generated.bidirectional_pb2 as bid

 

def run():
    channel = grpc.insecure_channel('localhost:50051')
    stub = bid.SpeakStub(channel)

Constructing a channel and a stub aren't enough to exchange messages; you must also invoke an RPC. From your .proto like the way to do that will be to add "my_response_iterator = stub.Message(<your iterator of request messages>)" to this client-side code (and then additional code doing whatever it is that you want to do with the responses that you receive). If you don't need to ever send any request messages, something like "iter(())" would be fine for <your iterator of request messages>.

if __name__ == '__main__':
  run()

 

server.py

def serve():
    server = grpc.server(futures.ThreadPoolExecutor(max_workers=10))
    bid.add_SpeakServicer_to_server(bid.SpeakServicer(),server)
    server.add_insecure_port('[::]:50051')
    server.start()
    print "[SERVER] start at 50051"
    try:
        while True:
            time.sleep(_ONE_DAY_IN_SECONDS)
    except KeyboardInterrupt:
        server.stop(0)

if __name__ == '__main__':
    serve()

but I don’t get where I should implement the servicer SpeakServicer(bid.BetaSpeakServicer) and how to invoke it for be that the server send the message to the client.

bidirectional_pb2.SpeakServicer is a do-nothing class that has an implementation of the Message method that raises NotImplementedError (right?). What we intend is for you to subclass bidirectional_pb2.SpeakServicer and override its implementation of the Message method with an implementation that does whatever you wish it to do. Then rather than instantiating bidirectional_pb2.SpeakServicer and passing that object to add_SpeakServicer_to_server, pass an instance of your subclass to add_SpeakServicer_to_server.

Where the proto file is

service Speak {

    rpc Message(stream Request) returns (stream Response){}

}

Can you help me?

I hope I have; please feel welcome to ask more!

-Nathaniel

[Mosca, Federico]

What is not so clear is if after the client call stub.message the server only 'reply' to that using the stream response and nothing else, is it correct?

Sever can not start a new exchanges of request/response to the client, right?

What we would like to do is:

-client invoke the rpc (there is no other way I understood)

-server ask something to the client

-client do something somewhere else and return result to the server

Is it doable? 

Thanks

Sorry for brevity and typos

Sent from iPhone

[Nathaniel Manista]

On Fri, Jul 29, 2016 at 10:02 AM, Mosca, Federico <federic...@here.com> wrote:

What is not so clear is if after the client call stub.message the server only 'reply' to that using the stream response and nothing else, is it correct?

Correct.

Sever can not start a new exchanges of request/response to the client, right?

Correct.

What we would like to do is:

-client invoke the rpc (there is no other way I understood)

-server ask something to the client

-client do something somewhere else and return result to the server

Is it doable?

This is doable and it will take just a little bit of control-flow gymnastics. It's perfectly fine for the client to invoke an RPC, the server to send a response, and then for the client to send a request (the names "request" and "response" are only used to identify the direction in which a message travels during the RPC, not whether it is sent before or after any other message). But it is the case that on the client-side an iterator of request messages must be passed at RPC invocation. What I think you will have to do, then, is write your own object that implements the iterator protocol but that does not emit a request object until after other code on the client-side has received a response (or many responses; up to you) and determined from that response (or those responses) the value of the request to send to the server. Then you can pass that object at RPC invocation; the client-side runtime will immediately ask it for a request value (by calling its next (Python 2) or __next__ (Python 3) method), but it won't actually return from that call until much later (after all the responses have been received).

How much do you like working with condition variables, events, blocking queues, and the like?

-Nathaniel

[iti...@gmail.com]

Not sure if this is still a question... i had a similar requirement and here's how a solution that am planning to use..

https://github.com/itisbsg/grpc-push-notif