In Process Transport?

[jeffdoolittle]

Are there plans to implement an In Process Transport?

https://github.com/grpc/grpc-java/tree/master/core/src/main/java/io/grpc/inprocess

Or perhaps this is already supported and I'm just not seeing it in the repository.

Thanks,

--Jeff

[JamesNK]

Is an inprocess transport using the gRPC client to call a gRPC server, but skip serialization and HTTP?

There are no plans to do that for 3.0.

If you want to support it, and you don't mind doing it yourself, you could implement a Grpc.Core.CallInvoker class and use it to talk directly to a service type.

[jeffdoolittle]

@JamesNK - what I have in mind does not involve calls over a network, and would not skip serialization. Instead of HTTP as the transport, something could be used like the inproc binding of NetMQ. Serialization has the benefit of preventing the passing of references between services running in the same process. Enabling both an HTTP and inproc transport would allow configuration of some services to use the standard HTTP transport for communicating over the network, but other services could run in process with one another, eliminating network latency. Using the same grpc programming model for both could be helpful.

While this may have some utility, the more I think about it, what I really want is something else entirely.

I conceive of a service as something that:

• exposes one or more contracts (not necessarily a .net interface, though that's certainly an option)
• hides information about data, logic, persistence, or anything else that can cause coupling to the internal implementation
• consistently performs expected behaviors
• provides consistent error handling

Coupling services to a transport means coupling a service to plumbing that has nothing to do with application logic. Plumbing exists between services and should be able to be swapped out with no changes to the four bullets above. I don't want to be coupled directly to the way gRPC defines its interfaces either, so for what I want to do, I'm going to need my own abstraction and I'll probably end up dropping down to the lower level gRPC capabilities as you mentioned in your last comment.

[JamesNK]

grpc-dotnet currently supports ASP.NET Core's TestServer. That allows gRPC calls to be made to an in-process .NET server.

In 5.0 we'll look at supporting gRPC over unix domain sockets and named pipes.

[shaggygi]

Based on the new Connections proposal, will it be possible to use custom transports/connections with grpc-dotnet? Just curious. Thx

[JamesNK]

Most likely. Once the changes to HttpClient are in a development build I will try them together with gRPC and other transports.

I would like .NET 5 to have documentation and samples for .NET + gRPC + named pipes/unix domain sockets.

[jeffdoolittle]

Let me know if I can help move this along in any way.

[jeffdoolittle]

Hi @JamesNK - any updates since June 15th?

[shaggygi]

There's an example now in the samples folder I believe.

[jeffdoolittle]

I see this:

https://github.com/grpc/grpc-dotnet/blob/ef77760676ce19c279d5480bca68af3ea4d60e96/test/FunctionalTests/Infrastructure/InProcessTestServer.cs

There are also a few places where the hosting model is set to InProcess, but I'm still looking for something along the lines of what @JamesNK mentioned above - #239 (comment)

[shaggygi]

It appears to be recently removed...

#1038
https://github.com/grpc/grpc-dotnet/blob/master/examples/Transporter

[jeffdoolittle]

Ah yes, this removal bit another project I follow as well: davidfowl/BedrockFramework#97 (comment)

Guess we're waiting for .NET 6 then.

[JamesNK]

The feature should come back early in .NET 6 previews, but using it will mean using preview builds.

Unfortunately nothing to do but wait.

[scalablecory]

We have an alternative for the connection abstractions feature in .NET 5 here: dotnet/runtime#41949