It would be useful to have a light-weight, low-overhead, in-process transport. It could be used in testing, using gRPC to an endpoint that may be in the same process, and bridging from other protocols (like REST or SOAP).

Today, we recommend using Netty's in-process transport for testing. This has the same benefit of using fakes, in that it tests more of the system's actual behavior. This still seems preferred for testing, but it does cause messages to be serialized and de-serialized.

For the design, I propose we implement an in-memory client/server transport (not a Channel/Server). Implementing a transport instead of Channel/Server lets Channel/Server continue to handle the listener threading model and would keep more behavior in sync (especially error handling). In order to prevent serializing messages, the InputStream passed to the transport would be the same InputStream passed out of the transport. Marshaller.parse() could then do an instanceof check and avoid serialization.

For example, for proto we would add something like the following to parse() in ProtoUtils, since messages are immutable:

if (stream instanceof DeferredProtoInputStream) {
  return ((DeferredProtoInputStream) stream).message();
}

The transport itself would not create any threads and do all its work in the caller's thread. I think it wouldn't even need to use locks for thread safety, as Stream is not thread-safe. If the application uses directExecutor for Channel and Server, then no threads would be created.

@jhump