-
Notifications
You must be signed in to change notification settings - Fork 420
Implementation Questions
Contributed by @MrMage:
-
What's the expected behavior when one of the parties cancels the call? E.g. when the client cancels a server-streaming request, how does the server know that it shouldn't send anything more?
It appears that to get the cancelled status, we should send a RECV_CLOSE_ON_SERVER op (https://github.com/grpc/grpc/blob/master/src/cpp/server/server_context.cc). Is this definitive?
-
Also, is there comprehensive documentation on how the C API is supposed to be used? There's the header docs, sure, but I was thinking more of a "this result needs to be released, this is supposed to happen when the call gets canceled, here you can get more info on the error etc.".
-
In particular, it seems like completion queue events contain almost no error information at all (unless their operation group contained receiveStatusFromServer). Can I somehow get info that a call was cancelled or has timed out, especially (but not limited to) from the server side?
-
From https://github.com/grpc/grpc/issues/9377 it sounds like the server can actually get informed when a call gets cancelled, I'd love to know how. (Right now it seems simply like the next operation I try to perform will have success = false, but that doesn't tell you why.)
-
In terms of timeouts: In client-streaming calls, it appears that instead of being informed that the connection timed out, the result looks more like an "endOfStream" to the server, i.e. the client has nothing more to send. (See the bottom of https://github.com/grpc/grpc-swift/blob/master/Tests/SwiftGRPCTests/ServerTimeoutTests.swift.)
-
Also, is there a way for the server to set a custom (or a maximum) timeout? Otherwise I could imagine a DoS attack where clients start a ton of calls, then never send anything again on that call.