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 On Friday, August 9, 2024 at 1:08:20 PM UTC-5 Larry Safran wrote: > 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 > > On Fri, Aug 9, 2024 at 10:26 AM Eric Robins <ericro...@gmail.com> wrote: > >> Last year I had posted a question >> <https://groups.google.com/g/grpc-io/c/IqDrqMKgduY/m/Kvr7W1bNAAAJ> 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 >> <https://docs.oracle.com/javase/8/docs/technotes/guides/security/jsse/JSSERefGuide.html#tls-protocol-overview>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... >> >> -- >> 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 >> >> <https://groups.google.com/d/msgid/grpc-io/b00f44cc-5f99-46e1-bc2b-f194a02f9183n%40googlegroups.com?utm_medium=email&utm_source=footer> >> . >> > -- 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/537b012b-b6c5-4360-bd0d-e6bf84c38498n%40googlegroups.com.
