From 0a588c6453026a8d11a328ced140745e6d0361f1 Mon Sep 17 00:00:00 2001 From: randvis Date: Mon, 12 Dec 2016 02:18:34 +0800 Subject: Fix the incorrect number of states There're five states: CONNECTING, READY, TRANSIENT_FAILURE, IDLE, SHUTDOWN. --- doc/connectivity-semantics-and-api.md | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) (limited to 'doc/connectivity-semantics-and-api.md') diff --git a/doc/connectivity-semantics-and-api.md b/doc/connectivity-semantics-and-api.md index cc007eaae3..6d39619d65 100644 --- a/doc/connectivity-semantics-and-api.md +++ b/doc/connectivity-semantics-and-api.md @@ -16,7 +16,7 @@ reconnect, or in the case of HTTP/2 GO_AWAY, re-resolve the name and reconnect. To hide the details of all this activity from the user of the gRPC API (i.e., application code) while exposing meaningful information about the state of a -channel, we use a state machine with four states, defined below: +channel, we use a state machine with five 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 @@ -116,7 +116,7 @@ Channel State API All gRPC libraries will expose a channel-level API method to poll the current state of a channel. In C++, this method is called GetCurrentState and returns -an enum for one of the four legal states. +an enum for one of the five legal states. All libraries should also expose an API that enables the application (user of the gRPC API) to be notified when the channel state changes. Since state -- cgit v1.2.3