With this changeset, ttrpc can now handle mutliple outstanding requests
and responses on the same connection without blocking. On the
server-side, we dispatch a goroutine per outstanding reequest. On the
client side, a management goroutine dispatches responses to blocked
waiters.
The protocol has been changed to support this behavior by including a
"stream id" that can used to identify which request a response belongs
to on the client-side of the connection. With these changes, we should
also be able to support streams in the future.
Signed-off-by: Stephen J Day <stephen.day@docker.com>
Rather than employ the typeurl package, we now generate code to
correctly allocate the incoming types from the caller. As a side-effect
of this activity, the services definitions have been split out into a
separate type that handles the full resolution and dispatch of the
method, incuding correctly mapping the RPC status.
This work is a pre-cursor to larger protocol change that will allow us
to handle multiple, concurrent requests.
Signed-off-by: Stephen J Day <stephen.day@docker.com>
With this changeset, we have the first end to end generated server and
client. Most of the necessary types are in place and working. There are
a lot of details to work out, but this would be enough for to exercise
the end to end flow.
Signed-off-by: Stephen J Day <stephen.day@docker.com>
The server unit test now manually mocks much of the generated code for a
given service, including back registration of the service. We avoid
having a package-level global descriptor in favor of a closures for the
handler dispatch function.
Signed-off-by: Stephen J Day <stephen.day@docker.com>
With this change, we define a simple server and client framework to
start generating code against. We define a simple handler system with
back registration into the server definition.
From here, we can start generating code against the handlers.
Signed-off-by: Stephen J Day <stephen.day@docker.com>
A varint prefixed framing format is defined for transport messages for
mgrpc. We may make changes to include a more structured frame, but this
initial work can be used to validate the concepts.
Signed-off-by: Stephen J Day <stephen.day@docker.com>
Set the stage for the example server by including a service definition,
generated code and the protobuild definition file used to generate them.
From here, we can work up to a generated mgrpc server.
Signed-off-by: Stephen J Day <stephen.day@docker.com>
