Following the convention of http2, we now use odd stream ids for client
initiated streams. This makes it easier to tell who initiates the
stream. We enforce the convention on the server-side.
This allows us to upgrade the protocol in the future to have server
initiated streams.
Signed-off-by: Stephen J Day <stephen.day@docker.com>
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>
