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/6f0b559a-d783-45e5-ad77-15647b4cc869n%40googlegroups.com.
