Merge pull request #18054 from tuanvcw/fixing_doc

Fix many typos in doc

doc/PROTOCOL-WEB.md

@@ -132,7 +132,7 @@ finalized and implemented in modern browsers
 
 Versioning
 
-* Special headers may be introduced to support features that may break compatiblity.
+* Special headers may be introduced to support features that may break compatibility.
 
 ---
 

doc/connection-backoff-interop-test-description.md

@@ -40,7 +40,7 @@ Procedure of client:
 1. Calls Start on server control port with a large deadline or no deadline,
 waits for its finish and checks it succeeded.
 2. Initiates a channel connection to server retry port, which should perform
-reconnections with proper backoffs. A convienent way to achieve this is to
+reconnections with proper backoffs. A convenient way to achieve this is to
 call Start with a deadline of 540s. The rpc should fail with deadline exceeded.
 3. Calls Stop on server control port and checks it succeeded.
 4. Checks the response to see whether the server thinks the backoffs passed the

doc/connectivity-semantics-and-api.md

@@ -43,7 +43,7 @@ connection because of a lack of new or pending RPCs. New RPCs  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,
+period, channels that are READY or CONNECTING switch to IDLE. Additionally,
 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).

doc/core/grpc-client-server-polling-engine-usage.md

@@ -17,7 +17,7 @@ This document talks about how polling engine is used in gRPC core (both on clien
 ### Making progress on Async `connect()` on sub-channels  (`grpc_pollset_set` usecase)
 - A gRPC channel is created between a client and a 'target'. The 'target' may resolve in to one or more backend servers.
 - A sub-channel is the 'connection' from a client to the backend server
-- While establishing sub-cannels (i.e connections) to the backends, gRPC issues async [`connect()`](https://github.com/grpc/grpc/blob/v1.15.1/src/core/lib/iomgr/tcp_client_posix.cc#L296) calls which may not complete right away.  When the `connect()` eventually succeeds, the socket fd is make 'writable'
+- While establishing sub-channels (i.e connections) to the backends, gRPC issues async [`connect()`](https://github.com/grpc/grpc/blob/v1.15.1/src/core/lib/iomgr/tcp_client_posix.cc#L296) calls which may not complete right away.  When the `connect()` eventually succeeds, the socket fd is make 'writable'
   - This means that the polling engine must be monitoring all these sub-channel `fd`s for writable events and we need to make sure there is a polling thread that monitors all these fds
   - To accomplish this, the `grpc_pollset_set` is used the following way (see picture below)
 

doc/core/transport_explainer.md

@@ -110,7 +110,7 @@ There are other possible sample timelines. For example, for client-side streamin
    - These correspond to a client issuing `WritesDone` which causes the server's
      `Read` to fail
 1. Server: send\_message, send\_trailing\_metadata
-   - These correpond to the server doing `Finish`
+   - These correspond to the server doing `Finish`
 
 The sends on one side will call their own callbacks when complete, and they will
 in turn trigger actions that cause the other side's recv operations to

doc/environment_variables.md

@@ -114,7 +114,7 @@ some configuration as environment variables that can be set.
   - ERROR - log only errors
 
 * GRPC_TRACE_FUZZER
-  if set, the fuzzers will output trace (it is usually supressed).
+  if set, the fuzzers will output trace (it is usually suppressed).
 
 * GRPC_DNS_RESOLVER
   Declares which DNS resolver to use. The default is ares if gRPC is built with
@@ -144,7 +144,7 @@ some configuration as environment variables that can be set.
 * GRPC_ARENA_INIT_STRATEGY
   Selects the initialization strategy for blocks allocated in the arena. Valid
   values are:
-  - no_init (default): Do not inialize the arena block.
+  - no_init (default): Do not initialize the arena block.
   - zero_init: Initialize the arena blocks with 0.
   - non_zero_init: Initialize the arena blocks with a non-zero value.
 

doc/naming.md

@@ -52,7 +52,7 @@ but may not be supported in other languages:
 - `ipv6:address[:port][,address[:port],...]` -- IPv6 addresses
   - Can specify multiple comma-delimited addresses of the form `address[:port]`:
     - `address` is the IPv6 address to use. To use with a `port` the `address`
-      must enclosed in literal square brakets (`[` and `]`).  Example: 
+      must enclosed in literal square brackets (`[` and `]`).  Example:
       `ipv6:[2607:f8b0:400e:c00::ef]:443` or `ipv6:[::]:1234`
     - `port` is the port to use.  If not specified, 443 is used.
 

doc/wait-for-ready.md

@@ -2,7 +2,7 @@ gRPC Wait for Ready Semantics
 =============================
 
 If an RPC is issued but the channel is in `TRANSIENT_FAILURE` or `SHUTDOWN`
-states, the RPC is unable to be transmited promptly. By default, gRPC
+states, the RPC is unable to be transmitted promptly. By default, gRPC
 implementations SHOULD fail such RPCs immediately. This is known as "fail fast,"
 but usage of the term is historical. RPCs SHOULD NOT fail as a result of the
 channel being in other states (`CONNECTING`, `READY`, or `IDLE`).