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/bcd4e15d-55af-4466-b8d4-e29a59c307c6n%40googlegroups.com.
