5 ms·

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 th

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?

jrs95 9y ago
In the case of Transmission I think it may have been used both as IPC and as a remote connection.
- melq 9y ago
  Yeah I think this is the way you access the xml-rpc api.
geofft 9y ago
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.
catfood 9y ago
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.
- DrJokepu 9y ago
  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?
  - johncolanduoni 9y ago
    Guarantee of preserved message boundaries? It’s the reason Unix domain sockets have SOCK_SEQPACKET and Windows named pipes have message mode.
  - cryptonector 9y ago
    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).
jonny_eh 9y ago
Better cross-platform support?
vardump 9y ago
At least on Windows, TCP performs better than named pipes.
kibibu 9y ago
Spotify does pretty much the same thing
Tobba_ 9y ago
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).
- atesti 9y ago
  >(except for Edge, which uses an undocumented IPC API). Do you have any links or things to google for?

jrs95 9y ago

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

melq 9y ago
Yeah I think this is the way you access the xml-rpc api.

geofft 9y ago

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.

catfood 9y ago

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.

DrJokepu 9y ago
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?
- johncolanduoni 9y ago
  Guarantee of preserved message boundaries? It’s the reason Unix domain sockets have SOCK_SEQPACKET and Windows named pipes have message mode.
- cryptonector 9y ago
  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).

jonny_eh 9y ago

Better cross-platform support?

vardump 9y ago

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

kibibu 9y ago

Spotify does pretty much the same thing

Tobba_ 9y ago

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).

atesti 9y ago
>(except for Edge, which uses an undocumented IPC API). Do you have any links or things to google for?