4f0aeb590b
Changes the TTRPC client logic so that sending and receiving with the server are in completely independent goroutines, with shared state guarded by a mutex. Previously, sending/receiving were tied together by reliance on a coordinator goroutine. This led to issues where if the server was not reading from the connection, the client could get stuck sending a request, causing the client to not read responses from the server. See [1] for more details. The new design sets up separate sending/receiving goroutines. These share state in the form of the set of active calls that have been made to the server. This state is encapsulated in the callMap type and access is guarded by a mutex. The main event loop in `run` previously handled a lot of state management for the client. Now that most state is tracked by the callMap, it mostly exists to notice when the client is closed and take appropriate action to clean up. Also did some minor code cleanup. For instance, the code was previously written to support multiple receiver goroutines, though this was not actually used. I've removed this for now, since the code is simpler this way, and it's easy to add back if we actually need it in the future. [1] https://github.com/containerd/ttrpc/issues/72 Signed-off-by: Kevin Parsons <kevpar@microsoft.com> |
||
|---|---|---|
| .github/workflows | ||
| cmd/protoc-gen-gogottrpc | ||
| example | ||
| plugin | ||
| .gitignore | ||
| channel_test.go | ||
| channel.go | ||
| client_test.go | ||
| client.go | ||
| codec.go | ||
| config.go | ||
| go.mod | ||
| go.sum | ||
| handshake.go | ||
| interceptor.go | ||
| LICENSE | ||
| metadata_test.go | ||
| metadata.go | ||
| README.md | ||
| server_linux_test.go | ||
| server_test.go | ||
| server.go | ||
| services_test.go | ||
| services.go | ||
| types.go | ||
| unixcreds_linux.go | ||
ttrpc
GRPC for low-memory environments.
The existing grpc-go project requires a lot of memory overhead for importing packages and at runtime. While this is great for many services with low density requirements, this can be a problem when running a large number of services on a single machine or on a machine with a small amount of memory.
Using the same GRPC definitions, this project reduces the binary size and
protocol overhead required. We do this by eliding the net/http, net/http2
and grpc package used by grpc replacing it with a lightweight framing
protocol. The result are smaller binaries that use less resident memory with
the same ease of use as GRPC.
Please note that while this project supports generating either end of the protocol, the generated service definitions will be incompatible with regular GRPC services, as they do not speak the same protocol.
Usage
Create a gogo vanity binary (see
cmd/protoc-gen-gogottrpc/main.go for an
example with the ttrpc plugin enabled.
It's recommended to use protobuild
to build the protobufs for this project, but this will work with protoc
directly, if required.
Differences from GRPC
- The protocol stack has been replaced with a lighter protocol that doesn't require http, http2 and tls.
- The client and server interface are identical whereas in GRPC there is a client and server interface that are different.
- The Go stdlib context package is used instead.
- No support for streams yet.
Status
TODO:
- Document protocol layout
- Add testing under concurrent load to ensure
- Verify connection error handling
Project details
ttrpc is a containerd sub-project, licensed under the Apache 2.0 license. As a containerd sub-project, you will find the:
information in our containerd/project repository.