←back to thread

Using gRPC for (local) inter-process communication (2021)

(www.mpi-hd.mpg.de)
86 points zardinality | 4 comments | 20 Nov 24 13:42 UTC | HN request time: 0.644s | source
Show context
pjmlp ◴[20 Nov 24 17:04 UTC] No.42195953[source]▶
> Using a full-featured RPC framework for IPC seems like overkill when the processes run on the same machine.

That is exactly what COM/WinRT, XPC, Android Binder, D-BUS are.

Naturally they have several optimisations for local execution.

replies(3): >>42196335 #>>42197280 #>>42201053 #
merb ◴[20 Nov 24 19:30 UTC] No.42197280[source]▶
Btw. Modern windows also superports Unix domain sockets, so if you have an app that has another service that will run on the same machine or on a different one it is not so bad to use grpc over uds.
replies(1): >>42197431 #
1. pjmlp ◴[20 Nov 24 19:49 UTC] No.42197431[source]▶
Nice idea, although it is still slower than COM.

COM can run over the network (DCOM), inside the same computer on its own process (out-proc), inside the client (in-proc), designed for in-proc but running as out-proc (COM host).

So for max performance, with the caveat of possibly damaging the host, in-proc will do it, and be faster than any kind of sockets.

replies(3): >>42197698 #>>42202005 #>>42202658 #
2. tgma ◴[20 Nov 24 20:17 UTC] No.42197698[source]▶
> COM can run over the network (DCOM)

Ah the good ol' Blaster worm...

https://en.wikipedia.org/wiki/Blaster_(computer_worm)

3. merb ◴[21 Nov 24 07:38 UTC] No.42202005[source]▶
Well if you need ipc to connect different languages, you will stay away from COM. Heck once you use anything but rust,c or c++ you should drop com. Even dotnet support for com is aweful. And if you ever written a outlook addin, than you will start hating com by yourself, thanks to god that Microsoft is going away from that
4. ◴[21 Nov 24 09:54 UTC] No.42202658[source]▶