MediatR.IPC 4.3.0

dotnet add package MediatR.IPC --version 4.3.0                
NuGet\Install-Package MediatR.IPC -Version 4.3.0                
This command is intended to be used within the Package Manager Console in Visual Studio, as it uses the NuGet module's version of Install-Package.
<PackageReference Include="MediatR.IPC" Version="4.3.0" />                
For projects that support PackageReference, copy this XML node into the project file to reference the package.
paket add MediatR.IPC --version 4.3.0                
#r "nuget: MediatR.IPC, 4.3.0"                
#r directive can be used in F# Interactive and Polyglot Notebooks. Copy this into the interactive tool or source code of the script to reference the package.
// Install MediatR.IPC as a Cake Addin
#addin nuget:?package=MediatR.IPC&version=4.3.0

// Install MediatR.IPC as a Cake Tool
#tool nuget:?package=MediatR.IPC&version=4.3.0                

MediatR.IPC

A simple IPC proxy for MediatR requests.

How it works

MediatR.IPC provides two public interfaces: a client and a server. The client interface implements ISender. The server takes a dependency on ISender, usually resolved via a DI container. Messages from the client to the server are serialized with protobuf-net. The IPC transport can use Named Pipes or Unix Domain Sockets.

Usage

All IPC requests need to be registered. This can be done via assembly scanning or explicit registration. Since IPCs have different app domains, the registration will need to be done on the client and server. I recommend using a shared assembly which does this for you.

Process 1 (Command Handler)
[ProtoContract(ImplicitFields = ImplicitFields.AllPublic)]
public record MyFancyCommand : IRequest<bool>
{
    public string Message { get; init; } = string.Empty;
}

public static async Task Main(string[] args)
{
    // Register the IPC requests on startup
    IPCMediator.UseTransport(IPCTransport.NamedPipe);
    IPCMediator.RegisterAssemblyTypes(Assembly.GetExecutingAssembly())
               .WithAttribute<IPCRequestAttribute>()
               .Where(...);
    IPCMediator.RegisterType<MyFancyCommand>();

    // Use the default runtime type model from protobuf-net
    IPCMediator.TypeModel = RuntimeTypeModel.Default;
        
    // Resolve the ISender, so the server can proxy incoming requests.
    ISender sender = MyContainer.Resolve<ISender>();
    
    // Run the server until the application is closed.
    var server = new MediatorServerPool(sender, poolName: "MyRequestPool", poolSize: 8);
    await server.Run();
}
Process 2 (Request sender)
public static async Task Main(string[] args)
{
    // Register the requests, just like in Process 1
    IPCMediator.UseTransport(IPCTransport.NamedPipe);
    ...
    IPCMediator.RegisterType<MyFancyCommand>();
        
    // Create an ISender, which can be consumed by the application.
    ISender ipcSender = new MediatorClientPool(poolName: "MyRequestPool", poolSize: 8);
    
    // All requests are sent via ipcSender are sent to and handled by Process 1,
    // and the response is sent back to Process 2.
    bool result = await ipcSender.Send<MyDto>(new MyFancyCommand { Message = "Hello!" });
    Console.WriteLine(result);
}

Registration

All requests sent to the client need to be registered on the client and the server. This allows for quick resolution of types, and little overhead during runtime.

Transports

There are two supported transport types: Named Pipes and Unix Domain Sockets. Transport is specified with

IPCMediator.UseTransport(IPCTransport.UnixDomainSocket)
    .WithOptions(new UnixDomainSocketOptions
    {
        SocketPrefix = "/tmp/",
        SocketSuffix = ".sock",
    });

You could also implement your own transport; a TCP transport for instance.

However, this can easily be expanded upon! Simply create an implementation of IStreamStratergy.

Notifications

Notifications are a work in progress. NotificationHandlers need to be registered in the DI container. IPC notifications would also need to be routed to the MediatorServer. Pull requests are most welcome!

Exceptions

Currently, exceptions thrown by request handlers are not serialized, and no type information is preserved. Exceptions can be huge, and there is no garantue that the client process has a reference to the Exception-type thrown. Ideas and suggestions are welcome!

Contributing

All forms of contribution are welcome! Here is a list of some much needed features.

  • Request cancellation with CancellationToken
  • Dynamic buffers for requests in MediatorServerBase
  • IPublisher implementation
  • Routing of INotification to INotificationHandler designated for IPC via DI container.
Product Compatible and additional computed target framework versions.
.NET net7.0 is compatible.  net7.0-android was computed.  net7.0-ios was computed.  net7.0-maccatalyst was computed.  net7.0-macos was computed.  net7.0-tvos was computed.  net7.0-windows was computed.  net8.0 was computed.  net8.0-android was computed.  net8.0-browser was computed.  net8.0-ios was computed.  net8.0-maccatalyst was computed.  net8.0-macos was computed.  net8.0-tvos was computed.  net8.0-windows was computed. 
Compatible target framework(s)
Included target framework(s) (in package)
Learn more about Target Frameworks and .NET Standard.

NuGet packages

This package is not used by any NuGet packages.

GitHub repositories

This package is not used by any popular GitHub repositories.

Version Downloads Last updated
4.3.0 289 10/15/2023
4.1.0 370 1/12/2023
4.0.1 361 10/29/2022
3.2.0 421 8/16/2022
3.1.0 438 5/16/2022
3.0.0 446 3/31/2022
2.1.0 444 2/26/2022
2.0.0 290 1/3/2022
1.1.2 350 9/2/2021
1.1.1 303 5/4/2021
1.1.0 356 4/25/2021
1.0.0 345 4/16/2021