Hacker News Reader

Comment by DrJokepu | Hacker News Reader

So basically this is a local web server that is used for IPC? Is there a reason to do local IPC over TCP/IP, rather than over named pipes / unix pipes, other than not knowing about the existence of named pipes / unix pipes?

View on HN

Better library support - the state of HTTP client and server libraries is a lot better than the state of other random RPC libraries, and developers tend to be more familiar with it these days too, so it's likely to get you a better product. And very few HTTP libraries support HTTP over named pipes or UNIX sockets.

That's how it should be done yeah. Developers on Windows seem to be really loose in their use of TCP or UDP for IPC. Even my mouse driver opens up a port on 0.0.0.0.

UDP for IPC seems to be especially crazy to me. I mean sending data over TCP to localhost is basically a memcpy(), what advantages could UDP possibly have in that context?

Guarantee of preserved message boundaries? It’s the reason Unix domain sockets have SOCK_SEQPACKET and Windows named pipes have message mode.

AF_LOCAL (Unix domain) sockets suck for datagram messaging because both end-points need a filesystem name -- you can't have the client end-point be anonymous! The simplest way to have an anonymous client is to send a datagram socketpair to the server in a datagram, this way the server can respond over the socketpair -- but this is complex and significantly slower than if Unix domain datagram sockets just supported anonymous clients.

Meanwhile, if you want to write an IPC library that's portable to WIN32 and POSIX, and just about any OS that supports TCP/IP, then TCP or UDP works very well. In fact, nothing else does. But of course, you have to publish the server port number (and at least a cookie for authentication) for this somewhere (e.g., in /tmp).

While they're certainly the correct way of doing this, named pipes don't provide too many benefits under Win32; other than this little problem and having to assign a port number, of course. They're harder to debug, require a whole new slew of I/O boilerplate ontop of your existing files/TCP/UDP sockets, suffer from a bunch of weirdness when connecting, etc.

They're also pretty slow, but that isn't much of a concern here - browsers do suffer from it though (except for Edge, which uses an undocumented IPC API).

>(except for Edge, which uses an undocumented IPC API).

Do you have any links or things to google for?

At least on Windows, TCP performs better than named pipes.

In the case of Transmission I think it may have been used both as IPC and as a remote connection.

Yeah I think this is the way you access the xml-rpc api.

Spotify does pretty much the same thing

Better cross-platform support?

Reply on news.ycombinator.com