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 [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 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/1982c9a7-a8f1-4524-b734-ff33a3d44962n%40googlegroups.com.
