Inter-process communication with gRPC

By James Newton-King

Apps on the same machine can be designed to communicate with each other. Operating systems provide technologies for enabling fast and efficient inter-process communication (IPC). Popular examples of IPC technologies are Unix domain sockets and Named pipes.

.NET provides support for inter-process communication using gRPC.

Get started

IPC calls are sent from a client to a server. To communicate between apps on a machine with gRPC, at least one app must host an ASP.NET Core gRPC server.

An ASP.NET Core gRPC server is usually created from the gRPC template. The project file created by the template uses Microsoft.NET.SDK.Web as the SDK:

<Project Sdk="Microsoft.NET.Sdk.Web">

  <ItemGroup>
    <PackageReference Include="Grpc.AspNetCore" Version="2.47.0" />
    <Protobuf Include="Protos\greet.proto" GrpcServices="Server" />
  </ItemGroup>

</Project>

The Microsoft.NET.SDK.Web SDK value automatically adds a reference to the ASP.NET Core framework. The reference allows the app to use ASP.NET Core types required to host a server.

It is also possible to add a server to existing non-ASP.NET Core projects. Add the Microsoft.AspNetCore.App framework to the project file:

<Project Sdk="Microsoft.NET.Sdk">

  <ItemGroup>
    <FrameworkReference Include="Microsoft.AspNetCore.App" />
    <PackageReference Include="Grpc.AspNetCore" Version="2.47.0" />
    <Protobuf Include="Protos\greet.proto" GrpcServices="Server" />
  </ItemGroup>

</Project>

The preceding project file:

• Adds a framework reference to Microsoft.AspNetCore.App. The framework reference allows non-ASP.NET Core apps, such as Windows Services, WPF apps, or WinForms apps to use ASP.NET Core APIs. The app can now use ASP.NET Core APIs to start an ASP.NET Core server.
• Adds gRPC requirements:
  • NuGet package reference to Grpc.AspNetCore.
  • .proto file.

Inter-process communication (IPC) transports

gRPC calls between a client and server on different machines are usually sent over TCP sockets. TCP is a great choice for communicating across a network or the Internet. However, IPC transports can offer performance advantages and better integration with OS features when the client and server are on the same machine.

.NET supports multiple IPC transports:

• Unix domain sockets (UDS) is a widely supported IPC technology. UDS is the best choice for building cross-platform apps, and it's usable on Linux, macOS, and Windows 10/Windows Server 2019 or later.
• Named pipes are supported by all versions of Windows. Named pipes integrate well with Windows security, which can be used to control client access to the pipe.
• Other IPC transports by implementing IConnectionListenerFactory and registering the implementation at app startup.

Cross-platform apps may want to use different IPC transports, depending on the current OS. An app can check the current operating system on startup and chose the desired transport for that platform:

var builder = WebApplication.CreateBuilder(args);
builder.WebHost.ConfigureKestrel(serverOptions =>
{
    if (OperatingSystem.IsWindows())
    {
        serverOptions.ListenNamedPipe("MyPipeName");
    }
    else
    {
        var socketPath = Path.Combine(Path.GetTempPath(), "socket.tmp");
        serverOptions.ListenUnixSocket(socketPath);
    }

    serverOptions.ConfigureEndpointDefaults(listenOptions =>
    {
        listenOptions.Protocols = HttpProtocols.Http2;
    });
});

Configure client and server

The client and server must be configured to use an inter-process communication (IPC) transport. For more information about configuring Kestrel and SocketsHttpHandler to use IPC:

• Inter-process communication with gRPC and Unix domain sockets
• Inter-process communication with gRPC and Named pipes

Note

Built-in support for Named pipes in ASP.NET Core requires .NET 8 or later. .NET 8 is currently in preview and will be released near the end of 2023.