5 ms·

Why does everybody use tcp ports instead of file sockets for local communication?

by jbverschoor 4y ago

pstuart 4y ago
2 guesses: ignorance, and an assumption that using tcp allows for seamless transition to another host.
- jbverschoor 4y ago
  Api is still socket api.. AF_INET vs AF_UNIX. It takes a few lines of code to have to option to switch between. Ignorance makes sense.. I guess full stack developers means people who can read the top 5 lines of a stack trace
  - macintux 4y ago
    > I guess full stack developers means people who can read the top 5 lines of a stack trace C'mon. Do I really need to quote the guidelines to you?
    - jbverschoor 4y ago
      Oh was not meant as a personal attack or anything. Just general state of the industry
- klabb3 4y ago
  I guess I'm ignorant then! When I looked up domain sockets and so on it turned out to be different APIs for different OS:s, and it's significantly nicer to rely on a single API surface from the std lib. Maybe it's a habit thing as well, but to me pipes are more esoteric and harder to find docs about than network sockets.
  - pstuart 4y ago
    > I guess I'm ignorant then! We all are in our own ways ;-). I pulled that comment out of my ass so I'm ok with being corrected as appropriate.
  - jbverschoor 4y ago
    But they are not (named) pipes, it’s the same api. Just speak http or whatever over the socket. Afaik, windows also seems to support it these days
inetknght 4y ago
> Why does everybody use tcp ports instead of file sockets for local communication? In my experience it's because Windows and mac developers aren't aware of local file sockets. Windows API, in particular, doesn't have a similar concept if I recall.
- duped 4y ago
  Windows has named pipes. MacOS has UDS and they're not terribly uncommon
  - eptcyka 4y ago
    Windows also supports UDS now.
    - sph 4y ago
      I've never seen the UDS acronym to refer to UNIX sockets. Just call them UNIX sockets.
      - eptcyka 4y ago
        They're called UNIX domain sockets. Just call them UDS.
        sph 4y ago
        On the most popular UNIX-like operating system, Linux, there's are literally zero references to UDS to mean UNIX domain sockets. $ sudo mandb $ man -K UDS The point is that acronyms that are not context appropriate and/or very uncommon are quite annoying to come across. I guess it was worth saving a dozen bytes not to write the full thing in the first place.
- 10000truths 4y ago
  Windows 10 has support for UNIX sockets.
searealist 4y ago
Unix domain sockets have a severe limitation that the path must be a maximum 108 characters.
- chrismonsanto 4y ago
  This limitation only applies to the file name, as you can chdir to the directory before bind/connect. Unfortunate but not a deal breaker
  - skissane 4y ago
    > you can chdir to the directory before bind/connect Since working directory is per-process not per-thread, this seems a great way to introduce race condition bugs. It also basically rules it out for anything meant to be used as a library or framework.
    - chrismonsanto 4y ago
      Working directory can be changed on a per-thread basis on Mac with pthread_chdir_np, and on Linux you can create a thread with the clone syscall and without the CLONE_FS flag to avoid sharing working directory with the rest of the process. I don't know about Windows.
      - skissane 4y ago
        I think the answer on Windows is "No". One could fork a subprocess, chdir()+socket() there, then pass the socket back to parent over another socket (opened maybe with socketpair().) Should work on any Unix-like which supports SCM_RIGHTS (which is almost everybody, apparently even obscure platforms like AIX, IBM i, z/OS). But not Windows, which doesn't (at least not yet, they may add it at some point.) Makes one really wish there was a bindat() call: int bindat(int sockfd, const struct sockaddr *addr, socklen_t addrlen, int dirfd); or maybe funixsockat: int funixsockat(int type, int dirfd, const char * name); which would combine socket() and bind() in a single call
concerned_ctzn 4y ago
tcp ports are much more versatile, you can expose it to the outside world as opposed to unix sockets. Now exposing an nfs server to the outside can lead to interesting possibilities: for example you can implement a local fuse file system which can be mounted remotely through the NFS. It's highly not recommended at this moment because there's no authentication implemented
- FullyFunctional 4y ago
  Is there any fundamental reason you couldn't do both? Presumably local sockets have less overhead (and I do prefer not to open ports unless needed).
lxgr 4y ago
Does the built-in macOS SMB client support mounting resources via file socket?
- jbverschoor 4y ago
  The bsd mount_nfs code uses AF_INET. Which makes sense. But I got triggered by the fact that is yet another app listening to ip
userbinator 4y ago
Because TCP is well-known and works both locally and over the network, on just about every networked operating system?
- jbverschoor 4y ago
  It’s not almost enough for all developers to not just simply bind to 0.0.0.0. It’s not well known enough, looking at the recent thread where people are amazed that the i notation is simply a 32bit number van can be used like that. Or even http://0xd1d8e6f0 http://0xd1d8e6f0 For example, even if you do vind to localhost, anyone on your system can access your service. Let’s say an electron is running on port 5555. A guest user on your system can just access the electron app. If this app happens to be vscode, you now have full access. It’s just plain stupid. You basically nuked multi user security. Better run dos then
  - zbentley 4y ago
    In practice these problems occur, but more rarely than you're implying. First, many of the systems that local-use-only-but-served-via-TCP-on-localhost apps use are not multi user. VS Code is a good example; I'd hazard that the vast majority of installs thereof are on systems that don't have simultaneous users logged in. Second, many localhost-tcp apps do use authentication of a sort; this is simple to set up via a secret that is pre-shared at application installation time. Third, it's easily possible to use ip[tables] to restrict loopback traffic based on conditions that include user ID or group ID. I'm not sure how many people take advantage of this capability, since doing so reliably would probably imply the "server" component having root so it could impose firewally restrictions on loopback users at startup time.
  - lproven 4y ago
    I cannot understand this. It may not just be me. Would you like to try again? > it's not almost enough... to not That is not a standard English structure and I can't unwrap all the negatives and follow it. > i notation (?) > van be used like that (?) "can be" > vind to localhost (?) "bind to" > an electron is running on port (?)

Why does everybody use tcp ports instead of file sockets for local communication?

pstuart 4y ago

2 guesses: ignorance, and an assumption that using tcp allows for seamless transition to another host.

jbverschoor 4y ago
Api is still socket api.. AF_INET vs AF_UNIX. It takes a few lines of code to have to option to switch between. Ignorance makes sense.. I guess full stack developers means people who can read the top 5 lines of a stack trace
- macintux 4y ago
  > I guess full stack developers means people who can read the top 5 lines of a stack trace C'mon. Do I really need to quote the guidelines to you?
  - jbverschoor 4y ago
    Oh was not meant as a personal attack or anything. Just general state of the industry
klabb3 4y ago
I guess I'm ignorant then! When I looked up domain sockets and so on it turned out to be different APIs for different OS:s, and it's significantly nicer to rely on a single API surface from the std lib. Maybe it's a habit thing as well, but to me pipes are more esoteric and harder to find docs about than network sockets.
- pstuart 4y ago
  > I guess I'm ignorant then! We all are in our own ways ;-). I pulled that comment out of my ass so I'm ok with being corrected as appropriate.
- jbverschoor 4y ago
  But they are not (named) pipes, it’s the same api. Just speak http or whatever over the socket. Afaik, windows also seems to support it these days

inetknght 4y ago

> Why does everybody use tcp ports instead of file sockets for local communication? In my experience it's because Windows and mac developers aren't aware of local file sockets. Windows API, in particular, doesn't have a similar concept if I recall.

duped 4y ago
Windows has named pipes. MacOS has UDS and they're not terribly uncommon
- eptcyka 4y ago
  Windows also supports UDS now.
  - sph 4y ago
    I've never seen the UDS acronym to refer to UNIX sockets. Just call them UNIX sockets.
    - eptcyka 4y ago
      They're called UNIX domain sockets. Just call them UDS.
      - sph 4y ago
        On the most popular UNIX-like operating system, Linux, there's are literally zero references to UDS to mean UNIX domain sockets. $ sudo mandb $ man -K UDS The point is that acronyms that are not context appropriate and/or very uncommon are quite annoying to come across. I guess it was worth saving a dozen bytes not to write the full thing in the first place.
10000truths 4y ago
Windows 10 has support for UNIX sockets.

searealist 4y ago

Unix domain sockets have a severe limitation that the path must be a maximum 108 characters.

chrismonsanto 4y ago
This limitation only applies to the file name, as you can chdir to the directory before bind/connect. Unfortunate but not a deal breaker
- skissane 4y ago
  > you can chdir to the directory before bind/connect Since working directory is per-process not per-thread, this seems a great way to introduce race condition bugs. It also basically rules it out for anything meant to be used as a library or framework.
  - chrismonsanto 4y ago
    Working directory can be changed on a per-thread basis on Mac with pthread_chdir_np, and on Linux you can create a thread with the clone syscall and without the CLONE_FS flag to avoid sharing working directory with the rest of the process. I don't know about Windows.
    - skissane 4y ago
      I think the answer on Windows is "No". One could fork a subprocess, chdir()+socket() there, then pass the socket back to parent over another socket (opened maybe with socketpair().) Should work on any Unix-like which supports SCM_RIGHTS (which is almost everybody, apparently even obscure platforms like AIX, IBM i, z/OS). But not Windows, which doesn't (at least not yet, they may add it at some point.) Makes one really wish there was a bindat() call: int bindat(int sockfd, const struct sockaddr *addr, socklen_t addrlen, int dirfd); or maybe funixsockat: int funixsockat(int type, int dirfd, const char * name); which would combine socket() and bind() in a single call

concerned_ctzn 4y ago

tcp ports are much more versatile, you can expose it to the outside world as opposed to unix sockets. Now exposing an nfs server to the outside can lead to interesting possibilities: for example you can implement a local fuse file system which can be mounted remotely through the NFS. It's highly not recommended at this moment because there's no authentication implemented

FullyFunctional 4y ago
Is there any fundamental reason you couldn't do both? Presumably local sockets have less overhead (and I do prefer not to open ports unless needed).

lxgr 4y ago

Does the built-in macOS SMB client support mounting resources via file socket?

jbverschoor 4y ago
The bsd mount_nfs code uses AF_INET. Which makes sense. But I got triggered by the fact that is yet another app listening to ip

userbinator 4y ago

Because TCP is well-known and works both locally and over the network, on just about every networked operating system?

jbverschoor 4y ago
It’s not almost enough for all developers to not just simply bind to 0.0.0.0. It’s not well known enough, looking at the recent thread where people are amazed that the i notation is simply a 32bit number van can be used like that. Or even http://0xd1d8e6f0 http://0xd1d8e6f0 For example, even if you do vind to localhost, anyone on your system can access your service. Let’s say an electron is running on port 5555. A guest user on your system can just access the electron app. If this app happens to be vscode, you now have full access. It’s just plain stupid. You basically nuked multi user security. Better run dos then
- zbentley 4y ago
  In practice these problems occur, but more rarely than you're implying. First, many of the systems that local-use-only-but-served-via-TCP-on-localhost apps use are not multi user. VS Code is a good example; I'd hazard that the vast majority of installs thereof are on systems that don't have simultaneous users logged in. Second, many localhost-tcp apps do use authentication of a sort; this is simple to set up via a secret that is pre-shared at application installation time. Third, it's easily possible to use ip[tables] to restrict loopback traffic based on conditions that include user ID or group ID. I'm not sure how many people take advantage of this capability, since doing so reliably would probably imply the "server" component having root so it could impose firewally restrictions on loopback users at startup time.
- lproven 4y ago
  I cannot understand this. It may not just be me. Would you like to try again? > it's not almost enough... to not That is not a standard English structure and I can't unwrap all the negatives and follow it. > i notation (?) > van be used like that (?) "can be" > vind to localhost (?) "bind to" > an electron is running on port (?)