Live data from Hacker News

65535 interfaces ought to be enough for anybody

aakinshin.net

31–40 of 82 posts

Re: 65535 interfaces ought to be enough for anybody

#31
post #22

Also: 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...

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.

Re: 65535 interfaces ought to be enough for anybody

#33

Earlier quoted context omitted.

The same is true of 32 bit numbers. 64 bits might finally be enough. crosses fingers

Well, for counts 32 bits is enough, unless you count something really small, like every individual byte in something. And for counts 64 bits should be enough, since it's 20 billion billion.

For counts of things you have in memory, 32 bits is usually enough -- even if each thing is just 8 bytes, 2^32 of those objects would require 32 GB.

Re: 65535 interfaces ought to be enough for anybody

#34
post #29

Earlier quoted context omitted.

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.

Easy to do with DNS SRV records. Just add: _http._tcp.hostname SRV priority weight port target. and you can use any available port you like. Of course, current TCP has 16-bit ports hard coded. But IPv6 has almost unlimited addresses. For some reason, SRV records are not in wide spread use.

>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.

Re: 65535 interfaces ought to be enough for anybody

#35
post #13

Earlier quoted context omitted.

A coworker mentioned that multidexing also take ages and uses huge amounts of memory.

Are there any legitimate use cases for that many methods?

Because of "single responsibility principle" it's better if classes and methods do one thing. That usually leads to lots of small classes and small methods.

Re: 65535 interfaces ought to be enough for anybody

#36

File this under 'premature optimization bites after 12 years'.

i'd argue the opposite.. i mean, i think you're referring to malloc when you cite premature optimisation, but this seems more of an issue of failing to optimise for the future or generalise beyond the initial needs of the developer

Re: 65535 interfaces ought to be enough for anybody

#37
post #22

Also: 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...

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.

Packet size is important. If your ports are strings, every packet gets that much bigger. Nobody wants slow internet for programming convenience.

Re: 65535 interfaces ought to be enough for anybody

#38
post #22

Also: 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...

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.

> Why not call the port "HTTP" instead

This is what /etc/services is for:

telnet localhost http ...

But unfortunately very few applications do resolve "port name to port number" as they resolve "hostname to ip address".

Re: 65535 interfaces ought to be enough for anybody

#39
post #22

Also: 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...

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.

Is it possible to file an RFC to IETF for these kinds of solutions? I see lot of great ideas but never see anybody proposing them anywhere, why?

Re: 65535 interfaces ought to be enough for anybody

#40
post #22

Also: 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...

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.

IIRC, appletalk used service names, not ports.
Post reply on HN