C#•11mo ago

Named Pipe IPC: Protocols & Status Codes

I'm basically starting from scratch with my implementation, since I've gone way too deep with my initial approach and need something that I can actually finally work with.

I'm writing an IPC implementation via named pipes. I'm open to other ideas (I don't know if anonymous pipes are appropriate here), but named pipes are definitely what I've settled on.
I cannot use additional NuGet packages and I'm on .NET Standard 2.0 (C# 13, PolySharp).

My requirements are the following:
I will have multiple server implementations. Each server fulfills a different purpose and has multiple methods (I will call them endpoints) pertaining to that purpose.
A server endpoint can be the equivalent to one of these:

Action

Action

Action<T>

Action<T>

Func<TResult>

Func<TResult>

Func<T, TResult>

Func<T, TResult>

. To clarify; an endpoint can optionally receive some request data, and can optionally return some response data.
Each server will be paired up with a client implementation that should simplify calling server endpoints for the user. These clients should return some
Result
Result
type to signal success or failure. If the server responds with a failure, the kind should be communicated to the client. This includes unhandled server exceptions.

My idea was to send data via JSON. The client serializes the request; sends it to the server; the server deserializes the data and calls the corresponding endpoint implementation. I'm not sure how to handle figuring out this correspondence.

I'm looking for some ideas on how to implement this in a manner that is reasonably robust and can be extended to more server-client-pairs without many problems.

eroOP•2/12/25, 1:22 PM

cc @Tanner Gooding @cap5lut if you'd like to take a peek
i'm gonna provide some more implementation ideas in a bit and you can tell me what i should do instead :p

eroOP•2/12/25, 1:29 PM

To be a bit less vague, this is about game interop. Unity, Unreal, GameMaker, etc. I need a different server-client-pair for each of those.
To determine the correspondence between the request data the server receives and the actual handler for that endpoint, I was thinking of simply using an enum or multipe enums. The thing that's in the way here is that all servers share some base requests, like . This makes using multiple enums a bit cumbersome.

Should I use strings instead?

eroOP•2/12/25, 1:41 PM

In terms of responses; I was initially using a different enum type for every endpoint in the server. This makes the entire implementation a big mess and was my main source of issues before.

I could possibly use integer status codes, but I'm afraid that will fall flat when it comes to unhandled server exceptions. Should I just send plain strings containing the reason for failure?

canton7•2/12/25, 1:41 PM

My idea was to send data via JSON

If you can't use nuget packages, and you don't have S.T.J, then the only json serializer you have is pretty rubbish

eroOP•2/12/25, 1:42 PM

oh, i can use that one actually. i use source generation with it. some others that i can use (provided by the app that i'm writing this plugin for) are and , for example

canton7•2/12/25, 1:47 PM

Is there a fully SG'd json library which doesn't need any runtime libraries at all? Which one?

eroOP•2/12/25, 1:48 PM

no no i just use stj

canton7•2/12/25, 1:48 PM

Ah no, I see what you mean

eroOP•2/12/25, 1:48 PM

i can technically use any package

eroOP•2/12/25, 1:49 PM

i il weave everything

eroOP•2/12/25, 1:49 PM

but i really want to keep the file size low

canton7•2/12/25, 1:49 PM

It looks like you've got a few different problems here:

Defining the different messages types
Mapping messages types into RPC methods to call
Serializing exceptions

Correct?

eroOP•2/12/25, 1:49 PM

i think that's a good summary

canton7•2/12/25, 1:50 PM

How are you defining your schema/interface? I.e. what messages can be sent between a given server and client?

canton7•2/12/25, 1:52 PM

(also note that json-rpc is a thing. Might be worth looking at what they do)

canton7•2/12/25, 1:52 PM

The normal way to approach something like this is that you define your schema centrally (i.e. what the message types are, what the parameters are, etc), then code-generate the server and client from that schema

canton7•2/12/25, 1:53 PM

The code generation handles converting method call -> message on the sender, and message -> method call on the receiver

Ccanton7 How are you defining your schema/interface? I.e. what messages can be sent betwe...

eroOP•2/12/25, 2:02 PM

i'm not sure how i should define them. simply the question of whether to use interfaces or not, whether to use classes or structs...
some of the data i would send would be like

eroOP•2/12/25, 2:03 PM

i really don't wanna write a source generator for this, and rpc libraries tend to be pretty large

canton7•2/12/25, 2:05 PM

Yeah, they're large for a reason! Chucking messages back and forth is a lot easier

eroOP•2/12/25, 2:05 PM

it's unfortunately not an option for me. i really want the download of the plugin to be quick

eroOP•2/12/25, 2:06 PM

i mean it's an option, but not the first i'd like to choose

canton7•2/12/25, 2:08 PM

Just to play devil's advocate -- can't you include any large libraries in your host application?

eroOP•2/12/25, 2:09 PM

the host application isn't mine

canton7•2/12/25, 2:10 PM

Ah, your IPC isn't with the host application?

eroOP•2/12/25, 2:11 PM

the ipc is between my library (loaded by the host app) and some game

eroOP•2/12/25, 2:11 PM

i'm essentially writing both sides, though

canton7•2/12/25, 2:11 PM

Ah gotcha

canton7•2/12/25, 2:12 PM

Can you just pass messages around, rather than going full-on RPC?

eroOP•2/12/25, 2:12 PM

that's exactly what i want to do

eroOP•2/12/25, 2:12 PM

the server side of course needs handlers

canton7•2/12/25, 2:13 PM

I thought you said you were turning method calls -> messages on the sender, and turning a message -> a method call on the receiver, with automatically serializing exceptions from that method call, etc?

eroOP•2/12/25, 2:17 PM

well, i thought i'd have some abstract base client, which contains the raw logic for sending over the request. there would then be several concrete clients which contain methods that hide this raw logic:

eroOP•2/12/25, 2:18 PM

where would serialize the request and just send it over the pipe

canton7•2/12/25, 2:20 PM

Yeah, it's the other side which gets a bit painful -- working out what the message type is, mapping that to a method to call, extracting the parameters, marshalling exceptions back, making sure that the response ends up in the same place that the request came from. Do-able, but boilerplatey if you're writing it by hand. At that point, you might as well just deal with the messages directly

canton7•2/12/25, 2:20 PM

Anyway, none of this is answering your original questions, I think

canton7•2/12/25, 2:20 PM

Ah no, it does cover:

I'm not sure how to handle figuring out this correspondence.

canton7•2/12/25, 2:25 PM

The short answer is:

Lots of hand-written boilerplate
Some method to register a method to a message type, but which reduces some of the boilerplate but probably introduces some runtime reflection / codegen
Compile-time code generation from a schema
Don't, and deal with the messages directly

canton7•2/12/25, 2:25 PM

(4 is what I do, FWIW)

cap5lut•2/12/25, 2:50 PM

u basically have this:
1) transport (fixed via named pipes i guess)
2) serialization (a bit of a struggle but u do it somehow)
3) application layer protocol
4) business logic

3 seems to be what u are stuck at, right?

eroOP•2/12/25, 2:50 PM

i've basically nuked the entire project :p

eroOP•2/12/25, 2:50 PM

so i'm at 0

cap5lut•2/12/25, 2:51 PM

well, then u have these 4 layers to work on

eroOP•2/12/25, 2:51 PM

which is what this thread is about :)

cap5lut•2/12/25, 3:39 PM

well, with 1 and 2 there arent problems are there?

eroOP•2/12/25, 3:42 PM

just in the sense that i was looking for possible alternatives if they make the process easier, more performant, more consistent, more in line with modern technologies

cap5lut•2/12/25, 3:44 PM

im not sure what ya mean by that. 1) would mean that u transfer a bunch of bytes, 2) would mean that u interpret that bunch of bytes.

cap5lut•2/12/25, 3:46 PM

"consistency and modern technologies" would be mostly in the application and business layer

cap5lut•2/12/25, 3:47 PM

the (de)serialization of 2) as well tho, but thats usually not the problematic thing

dance?•2/12/25, 9:16 PM

i still don't understand what your fear is about implementing this, or what is it that you don't know that require so much to think about