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.
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.
> 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.
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.
> 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.
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.
If you want to do a lookup translation and only use names on your local machine, it's only an hour of work or so to create a program that modifies the services file, and then make that program setuid root.
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.
> 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.
> > 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.
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.
Surely we can build some protocol on top of IP. I see people mention SRV records. These seem useful, however not very user-friendly at this point, so people don't use them.
DNS has SRV records. That is all you need, that is your solution, it exists. That they are not widely adopted in the manner you propose may be unfortunate, but completely upending protocols doesn't seem like a better or more realistically adopted solution either.
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.