> you suggest to stick with unary rpcs I would recommend to test all stability - / interrupt - / reconnect - scenarios before switching to a stream based communication completely. In my case I found much easier to handle all these edge-cases with unary calls.
> framework (on top of grpc?). Do you know any No - I do not know any framework here. For me the unary calls are comparable to TCP - you will get an acknowledge if the message was received correctly. The GRPC stream is more like an UDP communication - if you want to be sure, that a message is transmitted correctly you have to invent you own handshake. On Thursday, April 8, 2021 at 10:51:42 AM UTC+2 Filip Mrázek wrote: > Thank you Tobias for your answer. If I understand your answer, you suggest > to stick with unary rpcs and use already done communication framework (on > top of grpc?) . Do you know any which would be easy to learn and sufficient > for this case? Thank you > > Regards, > > Filip > Dne středa 7. dubna 2021 v 8:56:56 UTC+2 uživatel tobias.krueger napsal: > >> Hi Filip, >> >> from my experience streams are difficult to handle when it comes to a >> (un)reliable channels. >> Especially if you have to deal with crashing or ungraceful disconnecting >> clients. >> The client has no control if a sent packet has reached the server or not >> not. The same applies to the back channel: The server does not know if the >> client crashed or is just idle. >> >> IMHO it is also not feasible to invent your own handshake on top of an >> unreliable streamed channel - this is something that a communication >> framework can do better. >> I would stick with unary rpcs. >> >> Best regards >> >> >> On Tuesday, April 6, 2021 at 11:24:13 PM UTC+2 Filip Mrázek 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 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/3ee478c2-f08e-4b05-9d9e-918aba76a23bn%40googlegroups.com.
