Expose the raw connection from grpc server

[vishal-uttamchandani]

I maybe wrong but after going through the code, I don't see a way to access the raw connection from grpc Server. Is there a way on the server side to close a connection while leaving others open ?

Scenario:
Client connects to the server
Server does some work on behalf of the client. Sends data back to client
Client acks that it is done processing the message.
Server closes connection to the client (or if the timeout expires, connection closes anyways)

[dfawley]

@vishal-uttamchandani In gRPC, the client is responsible for ending connections, since it's typically the client that knows whether more requests might be sent. Do you have a use case where this doesn't work well?

[vishal-uttamchandani]

Essentially, I would like the server to be able to close the connection, if based on some business logic it decides that a particular client does not meet all the criteria to proceed.

[dfawley]

@vishal-uttamchandani connection-level controls on the server should typically be implemented in a handshaker. Once the connection is allowed, the client is responsible for ending the connection when it is no longer necessary.

Technically, you could pass data from the handshaker in AuthInfo that the service handler could access via the peer info, and this could include a function to close the connection. I would think hard before heading down this path, however, as this is not something I've ever heard of anyone wanting to do before.

Let us know if you have any further questions.

[vishal-uttamchandani]

@dfawley thanks for the info. My scenario is one where we don't trust the client to do the right thing and close the connection in time. This means even when the server work is done it will have to hang on to the connection. At scale, this means waste of resources. Any suggestion regarding this ?

[dfawley]

Even if you close the connection, the client will reconnect eagerly. In the future, we will detect idleness and have the client not reconnect, but that is not yet implemented.

Another option for you would be to use MaxConnectionIdle enforcement on the server. (This would not stop the reconnecting behavior, except I believe Java -- and possibly C -- clients will not eagerly reconnect after the resulting GOAWAY until the client attempts another RPC.)

https://godoc.org/google.golang.org/grpc/keepalive#ServerParameters
https://godoc.org/google.golang.org/grpc#KeepaliveParams