I sometimes wonder why we still use port numbers. Wouldn't it make much more sense to use strings to name ports?
For ephemeral ports, it isn't clear what value there would be for a string identifier vs. the fixed-width integer.
It's ancient, but still present on every Linux and MacOS system.
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.
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.
It'd still be a massive undertaking though.
Much less painful though because only the endpoints would need to know.
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.
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.
However it only works on your machine.
If you want to have it work on your local machine, DNS SRV records on your local network would work.
The proposal to use names and not numbers breaks down when you want the rest of the world to follow suit, because it's not technically possible within IP, only on top of IP.
This is exactly my point.
> This is exactly my point.
In which case, refer to my original response to your proposal - it's not practical to slow down every networking device in the world by a large factor.
It's like asking "why aren't we commuting at 1/3 the speed of light?": it's neither feasible nor practical.
Sure, it's possible, in that the physics involved make it possible, but not practical, because the limiting factor is not the physics involved.