Although it is spelling mistakes, it might make an affects while reading.
Co-Authored-By: Nguyen Phuong An <AnNP@vn.fujitsu.com>
Signed-off-by: Kim Bao Long <longkb@vn.fujitsu.com>
statuscodes.md is one of the top search results for "grpc status codes",
right behind codes.proto. Since this is a landing page for many people*,
and since the title and description of this page purports to be the
generic status codes documentation page, it seems like a good idea to define
terms before using them.
* Many people who are new to grpc/protobuf, for example, will be more
accustomed to and choose markdown files over .proto files.
* Expose the C-Core API in Cython layer
* Handle the object translation
* Create a separate package for Channelz specifically
* Handle nullptr and raise exception if seen one
* Translate C++ Channelz unit tests
* Adding 5 more invalid query unit tests
Adding peripheral utility for grpcio-channelz package
* Add to `pylint_code.sh`
* Add to Python build script
* Add to artifact build script
* Add to Bazel
* Add to Sphinx module list
* Use templates instead of generating them every time
* Theme changed
* Add grpc_* modules
* APIs grouped
* No documentation for class members without docstring
* Add docstring for status code
When security is disabled, not waiting for the HTTP/2 handshake can lead to
DoS-style behavior. For details, see:
https://github.com/grpc/grpc-go/issues/954. This requirement will incur an
extra half-RTT latency before the first RPC can be sent under plaintext, but
this is negligible and unencrypted connections are rarer than secure ones.
Under TLS, the server will effectively send its part of the HTTP/2 handshake
along with its final TLS "server finished" message, which the client must wait
for before transmitting any data securely. This means virtually no extra
latency is incurred by this requirement.
Go had attempted to separate "connection ready" with "connection successful"
(Issue: https://github.com/grpc/grpc-go/issues/1444 PR:
https://github.com/grpc/grpc-go/pull/1648). However, this is confusing to
users and introduces an arbitrary distinction between these two events. It has
led to several bugs in our reconnection logic (e.g.s
https://github.com/grpc/grpc-go/pull/2380,
https://github.com/grpc/grpc-go/pull/2391,
https://github.com/grpc/grpc-go/pull/2392), due to the complexity, and it makes
custom transports (https://github.com/grpc/proposal/pull/103) more difficult
for users to implement.
We are aware of some use cases (in particular,
https://github.com/soheilhy/cmux) expecting the behavior of transmitting an RPC
before the HTTP/2 handshake is completed. Before making behavior changes to
implement this, we will reach out to our users to the best of our abilities.
Mark D. Roth