Added the ability to create channels from client_channel_factory. This
will be used by the grpclb code to create the channels to communicate
with the LB servers.
Before it was possible for precompiled binaries of the Cython layer to
be downloaded during a test run if the metadata of the host machine's
gRPC Python project matched the metadata of a file in cloud storage. Now
we disallow this, and fix a bug where the relevant environment variable
was ineffectual.
This extends the existing http parser to support requests as well as responses.
httpcli continues to exist and work as it has previously, though in the new
directory src/core/http (to reflect the fact the directory now contains code
relevant to parsing requests, which httpcli would not generally involve itself
in).
On python3, in grpc._links.service._Kernel._on_service_acceptance_event,
there is a runtime TypeError:
```
_on_service_acceptance_event
group, method = service_acceptance.method.split('/')[1:3]
TypeError: 'str' does not support the buffer interface
```
It is fixed by using a bytes literal (`b'/'`) instead of a string literal.
This exposed another issue in grpc.beta._server where an exception was being
raised with a bytes literal for a message (a string should be used instead.)
Currently ByteBuffer.bytes() reads from the underlying grpc byte_buffer
a slice at a time, and appends each to a Python string (bytes). In
Python strings are immutable, so appending creates a new string by
copying the previous data. This means the current implementation is
quadratic.
The effect is very noticeable when messages have repeated (or large)
string fields. We traced execution between two services and observed
that when the payload size approached 600kb, the receiving service took
~10s at full CPU to read a response that had taken fractions of a second
the send over the network.
This commit changes ByteBuffer.bytes() to use an intermediate bytearray,
instead of strings, for the in-progress bytes. Once all slices are
read, the buffer is converted to a string.
Since the default behavior is quite sane, support just calling ssl_channel_credentials() without explicitly specifying ssl_channel_credentials(None, None, None).
This changes the pattern ssl_channel_credentials(server_crt, None, None) to ssl_channel_credentials(server_crt)
Signed-off-by: Christian Svensson <blue@cmd.nu>
Make insecure_channel / secure_channel accept port=None and only use the
'host' argument. This enables using UNIX sockets without mangling the
path of the socket.
Signed-off-by: Christian Svensson <blue@cmd.nu>