Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

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

mpi-hd.mpg.de

Post reply on HN
Print view View original

91–99 of 99 posts

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

#91

Post by fulladder »

pjmlp wrote: post #86
merb wrote: post #73

Earlier quoted context omitted.

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

Good luck with that goal, after Longhorn went down, all its design ideas were resurfaced as COM, and since Vista, COM (alongside with its WinRT makeover), is the main API model in Windows. Raw Win32 C API is stuck in Windows XP view of the world, with a few exceptions in some subsystems. Yes COM tooling sucks, which is kind of sad given that it is the main API model in modern Windows, but I guess WinDev suffers from…

I think I remember learning COM object programming in the late 1990s, and Longhorn would still have been an active project at that time. Been a long time, though, so maybe I'm mistaken.

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

#92

Post by pjmlp »

fulladder wrote: post #91
pjmlp wrote: post #86

Earlier quoted context omitted.

Good luck with that goal, after Longhorn went down, all its design ideas were resurfaced as COM, and since Vista, COM (alongside with its WinRT makeover), is the main API model in Windows. Raw Win32 C API is stuck in Windows XP view of the world, with a few exceptions in some subsystems. Yes COM tooling sucks, which is kind of sad given that it is the main API model in modern Windows, but I guess WinDev suffers from…

I think I remember learning COM object programming in the late 1990s, and Longhorn would still have been an active project at that time. Been a long time, though, so maybe I'm mistaken.

Yes, and?

COM history traces back to OLE, introduced in Windows 3.0 replacing DDE.

.NET was designed as COM replacement, however the way things went down was something else.

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

#93

Post by anilakar »

DanielHB wrote: post #84
anilakar wrote: post #19

In addition to cloud connectivity, we've been using MQTT for IPC in our Linux IIoT gateways and touchscreen terminals and honestly it's been one of the better architectural decisions we've made. Implementing new components for specific customer use cases could not be easier and the component can be easily placed on the hardware or on cloud servers wherever it fits best. I don't see how gRPC could be any worse than th…

Trying to understand an existing IoT codebase is scarier than reading Lovecraft. Out of curiosity, why were you using SSH reverse tunnel for IPC? Were you using virtualization inside your iot device and for some reason need a tunnel between the guests?

Reverse tunnel SSH was used for remote management. Once we replaced it with MQTT, we realized we could use it for IPC, too. I was not too clear about this in the post above.

Before MQTT we used whatever we had at hand; the touchscreen frontend (that ran Qt, not an embedded browser) talked to the local backend with HTTP. SMS messages were first sent to another local HTTP gateway and then via UNIX shm to a master process that templated the message to the smstools3 spool directory. A customer-facing remote management GUI ran on the device's built-in HTTP server but I no longer remember how it interfaced with the rest of the system. The touchscreen GUI might actually have had its own HTTP server for that, because it also handled Modbus communication to external I/O.

This was back in the day when everyone was building their own IoT platforms and obviously we were required to dogfood our own product, trying to make it do things it was never meant for. The gateway was originally designed to be an easy solution for AV integrators to remotely manage whole campuses from a single GUI. I'm pretty sure no customer ever wrote a line of code on the platform.

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

#94

Post by HumblyTossed »

ks2048 wrote: post #57
HumblyTossed wrote: post #3

> Using a full-featured RPC framework for IPC seems like overkill when the processes run on the same machine. However, if your project anyway exposes RPCs for public APIs or would benefit from a schema-based serialisation layer it makes sense to use only one tool that combines these—also for IPC. It might make sense. Usually , if you're using IPC, you need it to be as fast as possible and there are several solutions…

What are the other solutions that are much faster? (besides rolling your own mini format).

> What are the other solutions that are much faster?

Why ask the question, then

> (besides rolling your own mini format)

box it in?

Do you think I'm saying using an RPC is bad? I'm not. I simply took issue with the way the article was worded.

The thing about engineering is you don't want to do what some blogger says is best. You want to analyze YOUR particular needs and design your system from that. So, with every properly engineered solution there are trade-offs. You want easy? It may run slower. You want faster? You may have to roll your own.

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

#95

Post by tgma »

bunderbunder wrote: post #85
imtringued wrote: post #72

Earlier quoted context omitted.

Nobody does REST, because nobody needs the whole hateoas shtick. When people say REST, they mean "HTTP API" and I'm not being pendantic here. The difference is very real because REST doesn't really have a reason to exist.

But most HTTP APIs that are commonly described as REST still use those parts of REST-over-JSON-over-HTTP, even if they aren't truly RESTful. One thing I like about gRPC is that gRPC services use a single URL. And it doesn't ask you to define your own application error codes instead overloading HTTP status codes, thereby making it harder to distinguish application errors from communication channel errors. Things like…

> But it still tightly couples itself to other parts of HTTP, particularly HTTP 3

Incorrect. In fact, gRPC's primary implementation is HTTP/2 not /3. There are alternative implementation on top of QUIC, and other folks have implemented private transport implementations on top of high performance non-Ethernet networking.

The biggest I'd seen with proxies is that they didn't/don't fully implement HTTP/2 spec, in particular "trailers" which gRPC over HTTP/2 uses to transfer status code of each call.

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

#96

Post by lrem »

andy_ppp wrote: post #64
lrem wrote: post #52

Earlier quoted context omitted.

How does JSON protect you from that?

People understand JSON fairly commonly as they can see what is happening in a browser or any other system - what is the equivalent for GRPC if I want to do console.log(json)? GRPC for most people is a completely black box with unclear error conditions that are not as clear to me at least. For example what happens if I have an old schema and I'm not seeing a field, there's loads of things that can be wrong - old servi…

I'd go with `cerr I buy the familiarity argument, but I usually don't see the wire format at all. And maintenance-wise, protobufs seem easier to me. But that's because, e.g., someone set up a presubmit for me that yells at me if my change isn't backwards compatible. That's kind of hard to do if you don't have a formal specification of what goes into your protocol.

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

#97

Post by DanielHB »

anilakar wrote: post #93
DanielHB wrote: post #84

Earlier quoted context omitted.

Trying to understand an existing IoT codebase is scarier than reading Lovecraft. Out of curiosity, why were you using SSH reverse tunnel for IPC? Were you using virtualization inside your iot device and for some reason need a tunnel between the guests?

Reverse tunnel SSH was used for remote management. Once we replaced it with MQTT, we realized we could use it for IPC, too. I was not too clear about this in the post above. Before MQTT we used whatever we had at hand; the touchscreen frontend (that ran Qt, not an embedded browser) talked to the local backend with HTTP. SMS messages were first sent to another local HTTP gateway and then via UNIX shm to a master proce…

Ah okay, that makes more sense. We used wireguard for remote management and we never got into MQTT (I wish we had).

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

#98

Post by zbentley »

sgtnoodle wrote: post #60
eqvinox wrote: post #36

Earlier quoted context omitted.

Sorry, what's brawndo? (Searching only gives me movie results?) We started out discussing AF_UNIX vs. AF_INET6. If you can conceptually use something faster than sockets that's great, but if you're down to a socket, unix domain will generally beat inet domain...

You can do some pretty crazy stuff with pipes, if you want to do better than unix sockets.

Sure, but setting up a piped session with a pre-existing sidecar daemon can be complicated. You either end up using named pipes (badly behaved clients can mess up other clients’ connections, one side has to do weird filesystem polling/watching for its accept(2) equivalent), or unnamed pipes via a Unix socket with fdpass (which needs careful handling to not mess up, and you’re using a Unix socket anyway, so why not use it for data instead?).
Post reply on HN