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 sunanda...@gmail.com 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 <seni...@gmail.com> 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 sunanda...@gmail.com
>>> 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
>>> grpc-io+u...@googlegroups.com.
>>> 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 the Google Groups
"grpc.io" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to grpc-io+unsubscr...@googlegroups.com.
To view this discussion on the web visit
https://groups.google.com/d/msgid/grpc-io/15bd29ad-1056-4f31-ac30-432811daa5d3n%40googlegroups.com.
