I find it extremely awkward that we actually use numbers for ports. Port 80 is typically used for HTTP, but there's nothing preventing another application from using port 80. Why not call the port "HTTP" instead. Better yet why not give it an integer range of ports to go along with the naming - Eg MyApp[1], MyApp[2].
If you want to hide a port from being probed then give it a GUID as a name. No more port scans.
At the time TCP/UDP were invented, keeping packet size small was very important. A string or GUID as addressing information would have been out of the question.
(If there wasn't a need to distinguish multiple clients on the same machine, we might have only had 255 ports!)
A standard port for HTTP servers is needed, as most HTTP clients don't support DNS SRV records.
That said, in the IPv6 world there's no technical reason you can't just let every service bind a different IP address.
> in the IPv6 world there's no technical reason you can't just let every service bind a different IP address.
I'm not a networking expert, but is that true that you can create multiple ip's for a single device using ipv6? Sounds like it would end up very messy.
You can do that, provided that the network routes multiple IPs (or a whole prefix) to the device. It tends to be pretty messy keeping track of all the addresses in the OS configuration, but that's an opportunity for OSes to get better.
It's not even convenient. Strings are one of the biggest scourges of any programming language out there. Giant mess in basically every language until Java got it somewhat right, and even then don't forget your equals...
C# (.NET) could be the forerunner if only they had not gone with UTF16, but then it's only with hindsight that we can point out UTF8.
Strings are only a problem because they are being treated as text. In this case, they would simply be treated as binary identifiers, so there is no problem. The raw bytes would do just as well for this kind of thing.
Portmap[1] lets you use names instead of port numbers. A server just grabs an arbitrary port number and then registers itself with the portmap server. When you want to connect from a client, you first ask the portmap server for the port number.
>For some reason, SRV records are not in wide spread use.
No legacy tooling supports it. Poor support on the products already there. Huge numbers of firewalls are hard coded to 80:443 so alternate ports would be blocked.
When you make a poor choice on the internet, it lasts forever.
More practically, it's very nearly become a moot point due to firewalls which block all traffic except to a very narrow set of ports. Opening holes on enterprise firewalls is a gargantuan battle. Which is why we've seen what are effectively new services implemented as port 80 features: Twitter, Reddit, Facebook, Gmail, Dropbox just off the top of my head (irc, Usenet, finger, email, ftp, arguably, in their basic implementations).
Which is why when Apple moved to TCP/IP, multicast DNS (Bonjour, zeroconf) was such a crucial part, because it let them implement a similar model on top of port numbers.
The hard links issue often reared its head on Linux, because a sub-directory has a hard-link to its parent directory called "..". So you could only mkdir 32767 directories in any given directory, which hits you fairly fast if you try to do something like sorting numbered files into "000000/00.txt" etc
65535 tcp-ports ought to be enough for anybody [1]
65534 hardlinks ought to be enough for anybody [2]
[1] http://stackoverflow.com/questions/113224/what-is-the-larges...
[2] http://unix.stackexchange.com/questions/5629/is-there-a-limi...