Hi Filip, In the client-side code if you want to perform two or multiple rpc then you have to do that from the worker threads.
Thank you Tobias for suggesting multiple edge cases. Regards, Sunandan On Thu, Apr 15, 2021 at 6:07 PM Filip Mrázek <[email protected]> wrote: > > Hi Sunandan, > thank you for your answer. I tried your solution and it works (however I > didn't try edge cases which tobias mentioned). > Unfortunately I struggle with client in Python. To check everything work > on server side I used BloomRPC <https://github.com/uw-labs/bloomrpc>where > I can open stream, send messages over bidirectional stream, keep stream > opened, send unary rpcs, send messages over stream and then close the > stream. I followed the example > <https://grpc.io/docs/languages/python/basics/#client> provided by grpc > and my client code looks like this: > def msgs(): > messages = [ > pb.Command(name="first"), > pb.Command(name="second"), > pb.Command(name="third") > ] > for msg in messages: > yield msg > time.sleep(3) > > with grpc.insecure_channel("0.0.0.0:50000") as channel: > robot = Robot_pb2_grpc.RobotStub(channel) > > for response in robot.control(msgs()): > print(response) > > and I can't figure out how to send unary rpcs while the stream is still > open. > > (My aim is to create bidirectional stream for controlling robot (and > protect that only one client can open stream at the same time) and keep > unary rpcs for getting robot's properties such as position, current tool > used and so on) > Dne úterý 13. dubna 2021 v 10:06:23 UTC+2 uživatel tobias.krueger napsal: > >> Hi Sunandan, >> have you tried your sample some edge cases, where for example >> - you switch of a WLAN connection between client/server >> - plug-out the LAN cable before or after the switch >> - close a VPN connection that might be used. >> If you running the client and server on the same machine or you have a >> 1:1 cable in-between it is much more reliable. >> >> In my experience we have seen several cases where while loop is not be >> left reliable in a time, that is below my patience . >> We had to fiddle with the timeout parameters (GRPC_ARG_KEEPALIVE_TIME_MS >> etc.) to get an acceptable behavior after such interrupts . >> >> Best regards >> Tobias >> >> On Tuesday, April 13, 2021 at 9:55:02 AM UTC+2 [email protected] >> wrote: >> >>> Hi Filip, >>> >>> Sorry for the delayed response, >>> server sample code works like below >>> >>> grpc::Status StreamMethod(servercontext ..) >>> { >>> >>> ... >>> while(interface->Read()){ >>> >>> >>> }//if your client is killed then, your server Read will come out of >>> while >>> } >>> >>> So tested this in VS.If I close my client then server-side will come out >>> of this Reading () loop. >>> >>> Regards, >>> SN >>> >>> >>> On Wed, Apr 7, 2021 at 2:54 AM Filip Mrázek <[email protected]> wrote: >>> >>>> Hi, >>>> thak you for your reply. Client controls robot (after calling *connect >>>> *with master request) via several unary rpc calls (move, setTool, >>>> etc.). I was thinking about something like this: *rpc (stream Control) >>>> returns (stream ControlResponse), *but it's hard to create clean >>>> elegant *Control* message to contain everything needed. It would be >>>> nice to be able to send multiple message types. (and I think it's possible >>>> only with *oneof *nowadays, which I don't like, beacause every new >>>> command means to edit proto on two locations (new message type and adding >>>> message to oneof). >>>> Anyway, am I able to detect client cannot send request with stream? (he >>>> disconnected) How? Is there any example, please? >>>> Thanks. >>>> >>>> Regards, >>>> >>>> Filip. >>>> Dne úterý 6. dubna 2021 v 21:02:31 UTC+2 uživatel [email protected] >>>> napsal: >>>> >>>>> Hi Filip, >>>>> I believe I can understand your problem. >>>>> >>>>> As you have mentioned your client is master or controller for Robot, >>>>> right? >>>>> In that case how are you sending the control instruction to the robot, >>>>> is there any stream then you can easily detect the client disconnection. >>>>> If you are reading at server end when the client dies the read will >>>>> not return true, so you can understand from there. >>>>> >>>>> Otherwise you have to introduce some new API to notify client >>>>> disconnection and keep that call in catch() block somehow. That may help. >>>>> >>>>> Regards, >>>>> SN >>>>> >>>>> On Friday, 2 April 2021 at 16:13:21 UTC+5:30 Filip Mrázek wrote: >>>>> >>>>>> Hi, >>>>>> I would like to write gRPC server in C++, which is able to detect if >>>>>> client disconnected from the channel (client crashed or closed app). I >>>>>> need >>>>>> this, because server manages a physical robot and only one client can >>>>>> controll the robot at the same time (other clients can check only robot's >>>>>> properties such as position and so on). >>>>>> I've got *rpc connect(ConnectionInfo) returns(Token) *where >>>>>> ConnectionInfo contains information wheater client wants to control robot >>>>>> (wants to be master) or not and if it's possible, server returns access >>>>>> token. After the master client disconnects, I want to remove token from >>>>>> server to able other clients connect as master. >>>>>> The only solution I found out is to have *rpc disconnect() >>>>>> returns(Empty)*, but I doesn't cover case when client crash or just >>>>>> forget to call *disconnect *and robot is blocked*.* >>>>>> Is it possible with c++ gRPC, or what whould you recommend as the >>>>>> best solution fot this problem? >>>>>> Thank you very much. >>>>>> >>>>>> Filip. >>>>>> >>>>>> PS: I found several discussions, but none of them is helpful. >>>>>> https://groups.google.com/g/grpc-io/c/C0rAhtCUhSs/m/SzFDLGqiCgAJ >>>>>> https://groups.google.com/g/grpc-io/c/EIcQlLqlNQg >>>>>> >>>>> -- >>>> You received this message because you are subscribed to a topic in the >>>> Google Groups "grpc.io" group. >>>> To unsubscribe from this topic, visit >>>> https://groups.google.com/d/topic/grpc-io/KRhWNAoPUO8/unsubscribe. >>>> To unsubscribe from this group and all its topics, send an email to >>>> [email protected]. >>>> To view this discussion on the web visit >>>> https://groups.google.com/d/msgid/grpc-io/e906121c-5710-48ea-a40f-ff313fe70779n%40googlegroups.com >>>> <https://groups.google.com/d/msgid/grpc-io/e906121c-5710-48ea-a40f-ff313fe70779n%40googlegroups.com?utm_medium=email&utm_source=footer> >>>> . >>>> >>> -- > You received this message because you are subscribed to a topic in the > Google Groups "grpc.io" group. > To unsubscribe from this topic, visit > https://groups.google.com/d/topic/grpc-io/KRhWNAoPUO8/unsubscribe. > To unsubscribe from this group and all its topics, send an email to > [email protected]. > To view this discussion on the web visit > https://groups.google.com/d/msgid/grpc-io/15bd29ad-1056-4f31-ac30-432811daa5d3n%40googlegroups.com > <https://groups.google.com/d/msgid/grpc-io/15bd29ad-1056-4f31-ac30-432811daa5d3n%40googlegroups.com?utm_medium=email&utm_source=footer> > . > -- 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 [email protected]. To view this discussion on the web visit https://groups.google.com/d/msgid/grpc-io/CAKPYA20sd-YAgFEWDbp%3DX7tArw80HVGACDuDYO69S%2BT4zVknyQ%40mail.gmail.com.
