diff --git a/doc/connectivity-semantics-and-api.md b/doc/connectivity-semantics-and-api.md index 842ff8adc18..930dff265fe 100644 --- a/doc/connectivity-semantics-and-api.md +++ b/doc/connectivity-semantics-and-api.md @@ -20,7 +20,7 @@ channel, we use a state machine with four states, defined below: CONNECTING: The channel is trying to establish a connection and is waiting to make progress on one of the steps involved in name resolution, TCP connection -establishment or TLS handshake. This is the initial state for all channels upon +establishment or TLS handshake. This may be used as the initial state for channels upon creation. READY: The channel has successfully established a connection all the way @@ -34,14 +34,26 @@ retries are done with exponential backoff, channels that fail to connect will start out spending very little time in this state but as the attempts fail repeatedly, the channel will spend increasingly large amounts of time in this state. For many non-fatal failures (e.g., TCP connection attempts timing out -because the server is not yet available), the channel may be stuck in this -state for an indefinitely large amount of time. - -FATAL_FAILURE: There has been a fatal failure and the channel will never -attempt to establish a connection again. (e.g., a server presenting an invalid -TLS certificate) - -Channels that enter this state never leave this state. +because the server is not yet available), the channel may spend increasingly +large amounts of time in this state. + +IDLE: This is the state where the channel is not even trying to create a +connection because of a lack of new or pending RPCs. New channels MAY be created +in this state. Any attempt to start an RPC on the channel will push the channel +out of this state to connecting. When there has been no RPC activity on a channel +for a specified IDLE_TIMEOUT, i.e., no new or pending (active) RPCs for this +period, channels that are READY or CONNECTING switch to IDLE. Additionaly, +channels that receive a GOAWAY when there are no active or pending RPCs should +also switch to IDLE to avoid connection overload at servers that are attempting +to shed connections. We will use a default IDLE_TIMEOUT of 300 seconds (5 minutes). + +SHUTDOWN: This channel has started shutting down. Any new RPCs should fail +immediately. Pending RPCs may continue running till the application cancels them. +Channels may enter this state either because the application explicitly requested +a shutdown or if a non-recoverable error has happened during attempts to connect +communicate . (As of 6/12/2015, there are no known errors (while connecting or +communicating) that are classified as non-recoverable) +Channels that enter this state never leave this state. The following table lists the legal transitions from one state to another and corresponding reasons. Empty cells denote disallowed transitions. @@ -52,14 +64,16 @@ corresponding reasons. Empty cells denote disallowed transitions. CONNECTING READY TRANSIENT_FAILURE - FATAL_FAILURE + IDLE + SHUTDOWN CONNECTING Incremental progress during connection establishment All steps needed to establish a connection succeeded Any failure in any of the steps needed to establish connection - Fatal failure encountered while attempting a connection. + No RPC activity on channel for IDLE_TIMEOUT + Shutdown triggered by application. READY @@ -67,7 +81,8 @@ corresponding reasons. Empty cells denote disallowed transitions. Incremental successful communication on established channel. Any failure encountered while expecting successful communication on established channel. - + No RPC activity on channel for IDLE_TIMEOUT
OR
upon receiving a GOAWAY while there are no pending RPCs. + Shutdown triggered by application. TRANSIENT_FAILURE @@ -75,6 +90,15 @@ corresponding reasons. Empty cells denote disallowed transitions. + Shutdown triggered by application. + + + IDLE + Any new RPC activity on the channel + + + + Shutdown triggered by application. FATAL_FAILURE @@ -82,6 +106,7 @@ corresponding reasons. Empty cells denote disallowed transitions. +