3 ms·

/etc/services assigns a string to every port number. It's ancient, but still present on every Linux and MacOS system.

amelius 3y ago
Yeah, but it's still port numbers under the hood. The big downside of this is that you can get clashes. For example, VNC uses 5901 and up on my system. What if I have some other service that uses ports in the same range? A more sane approach would be to call those ports e.g. vnc/work, vnc/meeting, etc. so there would be no conflicts and you would know what each port is used for. And it would work even if you don't have write-access to /etc/services.
- HL33tibCe7 3y ago
  The reason this hasn't been done is that it would require changes to the headers of TCP and UDP, which would be a massive undertaking (for similar reasons to why IPv4 -> IPv6 is such a pain). Would both the source and destination ports both be strings? Normally, for a client->server packet, the source port is meaningless, so what string would you use? Or would your new protocol support both string ports and integer ports? Having ports be strings in the TCP header would make the header considerably longer - supposing your protocol had one fixed length 32 ASCII char string port, you'd be looking at something in the region of a 2x increase in header length.
  - Wingy 3y ago
    Couldn't the port string be mapped to a temporary port number when the TCP connection is initiated? It'd still be necessary for UDP though. It'd still be a massive undertaking though.
    - GauntletWizard 3y ago
      Yes, and there's already mechanisms for doing just that - look up DNS SRV records: https://en.m.wikipedia.org/wiki/SRV_record https://en.m.wikipedia.org/wiki/SRV_record
  - Dylan16807 3y ago
    > for similar reasons to why IPv4 -> IPv6 is such a pain Much less painful though because only the endpoints would need to know.
    - deleted 3y ago
      [deleted]
- lelanthran 3y ago
  > A more sane approach would be to call those ports e.g. vnc/work, vnc/meeting, etc. so there would be no conflicts and you would know what each port is used for. More sane, but absolutely slow. Every gateway, NAT, firewall, router and switch between two devices would need 15x more RAM, and even with that RAM would need to parse strings, deal with unicode, etc. All of those are slow operations. Using 16-bit numbers makes identification and routing of packets very quick.
  - amelius 3y ago
    It would also be faster if we referred to files by their inode numbers. But we have filenames, and I don't want to speak for everybody but I think people like them.
    - lelanthran 3y ago
      > It would also be faster if we referred to files by their inode numbers. But we have filenames, and I don't want to speak for everybody but I think people like them. Actually, we do refer to files by their inode number, not by their name. The system uses the name to lookup the inode number, and then use the inode number. Maybe I misunderstood you initially[1], but you weren't proposing to keep the numbers and use a lookup service for the name. AIUI, you proposed to replace the number with a name, no? In which case, absolutely no one is proposing to replace inode numbers with names, so inode numbers/filenames as an example does not validate or lend support to your proposal for replacing port numbers with names. [1] I'm on a personal quest to stop misunderstanding people in a way that reduces the strength of their argument. It's not going as well as I though it would, and I still do it sometimes.
      - amelius 3y ago
        Well, frankly I don't care how the ports are implemented, by numbers would be fine. As long as it means that from the user's point of view they are names. A config file like /etc/services is too simple because I create ports all the time, even from scripts, and I don't want to always become root to change the config; and other systems that want to connect to ports on my machine can't read /etc/services on my machine.

Yeah, but it's still port numbers under the hood. The big downside of this is that you can get clashes. For example, VNC uses 5901 and up on my system. What if I have some other service that uses ports in the same range? A more sane approach would be to call those ports e.g. vnc/work, vnc/meeting, etc. so there would be no conflicts and you would know what each port is used for. And it would work even if you don't have write-access to /etc/services.

HL33tibCe7 3y ago
The reason this hasn't been done is that it would require changes to the headers of TCP and UDP, which would be a massive undertaking (for similar reasons to why IPv4 -> IPv6 is such a pain). Would both the source and destination ports both be strings? Normally, for a client->server packet, the source port is meaningless, so what string would you use? Or would your new protocol support both string ports and integer ports? Having ports be strings in the TCP header would make the header considerably longer - supposing your protocol had one fixed length 32 ASCII char string port, you'd be looking at something in the region of a 2x increase in header length.
- Wingy 3y ago
  Couldn't the port string be mapped to a temporary port number when the TCP connection is initiated? It'd still be necessary for UDP though. It'd still be a massive undertaking though.
  - GauntletWizard 3y ago
    Yes, and there's already mechanisms for doing just that - look up DNS SRV records: https://en.m.wikipedia.org/wiki/SRV_record https://en.m.wikipedia.org/wiki/SRV_record
- Dylan16807 3y ago
  > for similar reasons to why IPv4 -> IPv6 is such a pain Much less painful though because only the endpoints would need to know.
  - deleted 3y ago
    [deleted]
lelanthran 3y ago
> A more sane approach would be to call those ports e.g. vnc/work, vnc/meeting, etc. so there would be no conflicts and you would know what each port is used for. More sane, but absolutely slow. Every gateway, NAT, firewall, router and switch between two devices would need 15x more RAM, and even with that RAM would need to parse strings, deal with unicode, etc. All of those are slow operations. Using 16-bit numbers makes identification and routing of packets very quick.
- amelius 3y ago
  It would also be faster if we referred to files by their inode numbers. But we have filenames, and I don't want to speak for everybody but I think people like them.
  - lelanthran 3y ago
    > It would also be faster if we referred to files by their inode numbers. But we have filenames, and I don't want to speak for everybody but I think people like them. Actually, we do refer to files by their inode number, not by their name. The system uses the name to lookup the inode number, and then use the inode number. Maybe I misunderstood you initially[1], but you weren't proposing to keep the numbers and use a lookup service for the name. AIUI, you proposed to replace the number with a name, no? In which case, absolutely no one is proposing to replace inode numbers with names, so inode numbers/filenames as an example does not validate or lend support to your proposal for replacing port numbers with names. [1] I'm on a personal quest to stop misunderstanding people in a way that reduces the strength of their argument. It's not going as well as I though it would, and I still do it sometimes.
    - amelius 3y ago
      Well, frankly I don't care how the ports are implemented, by numbers would be fine. As long as it means that from the user's point of view they are names. A config file like /etc/services is too simple because I create ports all the time, even from scripts, and I don't want to always become root to change the config; and other systems that want to connect to ports on my machine can't read /etc/services on my machine.