ServerTransportFilter is experimental

[ejona86]

Added in #2132

[ejona86]

@rmichela wrote in #2132:

I can't figure out how ServerTransportFilter is useful in its current form, since it provides so little information about the server transport from which to make any meaningful decision. In its current implementation, the only information I can learn about the transport is the client's remote address.

The only use I can see for a ServerTransportFilter is as a way to note that a connection starts and stops existing. Perhaps that is the only purpose.

[ejona86]

@rmichela, what additional information would you find useful?

[bcarter97]

Very late to the party but I am trying to configure metrics for server connections using the ServerTransportFilter. I think at the very least it would be useful to expose the rpc_service and rpc_method if possible? Or is that not something that makes sense at a connection level?

[ejona86]

@bcarter97, RPC information is per-RPC and is not known when the connection is created (and can change with every RPC during the life of the connection). So that's not feasible.

[bcarter97]

Thanks for the quick reply 😃 can we assume that the transportReady and transportTerminated events accurately reflect the number of connections open on the gRPC service?

[ejona86]

A connection exists before transportReady, because it is being handshaked (TCP, TLS, HTTP/2). So it would reflect the number of connections that can receive RPC traffic.