Understanding how the channel and transport layers are connected

[Eric Robins]

Last year I had posted a question about the concept of sessions in gRPC and the security around them.  This question is related to that.

I'm currently digging through the Java implementation of gRPC (gRPC-core and grpc-netty-shaded) and I'm trying to see if I can find where transport errors or alerts translate into channels being closed.  Specifically, I'd like to be able to show that if at the transport layer a TLS fatal alert is detected, that the channel on which that TLS session was riding is closed.

Assuming Java's JSSE is used for TLS for the purpose of this discussion, I can trace through the library where fatal alerts are discovered (SSLSocketImpl) during attempts to read/write data. The connection is closed and an IOException is thrown that propagates up the stack; it is expected that whatever client was using the library will catch the exception and deal with it.  What I can't find is where at the Channel layer that equates to a response by both client and server to close out that channel and, if necessary, establish a new one (where again authentication might take place).

Any helping pointing me to the right spot in the code will be a great help.

Eric

FYI - will be at gRPConf in a few weeks...

[Larry Safran]

Hi Eric,

  You need to differentiate between Channels, Subchannels and Calls (RPCs).  The transport connection is at the subchannel level and an exception there will cause the subchannel to go into TRANSIENT_FAILURE state which will cause the RPC to be cancelled (or retried).  The Channel itself is a logical concept and its exact behavior will depend on which load balancer it is configured with, but will not itself close because a subchannel is no longer available.  Each time an RPC starts (or retries) on a channel, gRPC uses the LoadBalancer to Pick a subchannel to use for communication.  If subchannels for all addresses returned by the Name Resolver go into TRANSIENT_FAILURE, then the Channel itself will go into TRANSIENT_FAILURE and defer any RPC requests until a working Subchannel can be established.

-- Larry

--
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+u...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/grpc-io/b00f44cc-5f99-46e1-bc2b-f194a02f9183n%40googlegroups.com.

[Eric Robins]

Thanks Larry for the response.  This type of detail is exactly that for what I'm looking.  I'm willing to read if you have documentation to which you can point me that explains the gRPC protocol at this level.

Eric

[Larry Safran]

There is a video of Eric Anderson's talk from 5 years ago at Kubecon https://www.youtube.com/watch?v=Naonb2XD_2Q that goes into a lot of the internal activity.

The gRFCs in https://github.com/grpc/proposal go into a lot of detail, but with the way they build on each other over time can be confusing to read through.

The documentation in https://grpc.io/docs/ is fairly extensive, but aimed at people who want to use gRPC, not understand its internals.

-- Larry

To view this discussion on the web visit https://groups.google.com/d/msgid/grpc-io/537b012b-b6c5-4360-bd0d-e6bf84c38498n%40googlegroups.com.