Live data from Hacker News

65535 interfaces ought to be enough for anybody

aakinshin.net

61–70 of 82 posts

Re: 65535 interfaces ought to be enough for anybody

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

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

See Meredith L. Patterson's "On Port 80" https://medium.com/@maradydd/on-port-80-d8d6d3443d9a

Re: 65535 interfaces ought to be enough for anybody

#62

Earlier quoted context omitted.

0 Interfaces 1 Interface ... 65535 Interfaces

I can't tell if you're joking, but when you're counting a quantity, you don't start from 0.

I suspect it is a play on the 0, 1, infinity rule.

Re: 65535 interfaces ought to be enough for anybody

#63

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.

IIRC, appletalk used service names, not ports.

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.

Re: 65535 interfaces ought to be enough for anybody

#66
post #56

Earlier quoted context omitted.

Java's crippled generics, lack of tuple support, and lack of default parameters encourage interface bloat in utility libraries. Given how bloody good Java IDEs are (By which I mean to say - how good IntelliJ is), the cognitive cost of this interface bloat is very low... Until you start developing for Android.

Wouldn't Java's crippled generics actually help reduce the method count since due to type erasure they're all the same method at the VM level anyway?

For reference types probably yes, but Java also often needs extra methods or overloads for handling primitive types, which would get unnecessarily boxed when used in generic methods.

Re: 65535 interfaces ought to be enough for anybody

#67

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.

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

The name could be used for connection establishment, then a random port is assigned, just like the client port.

Re: 65535 interfaces ought to be enough for anybody

#68

Earlier quoted context omitted.

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.

32GB isn't an exceptional amount of memory these days.

Sure -- but it is an exceptional amount of memory to use for tiny objects like those. If you're working with four billion objects at a time, they're probably more substantial than eight bytes.

Re: 65535 interfaces ought to be enough for anybody

#69
post #58

Earlier quoted context omitted.

Surely that's just a release build, though...? How would this bottleneck productivity for a team?

When you deploy release-like builds to your QA team (as you should), a tripled-build time is a bit problematic if you're trying to iterate quickly.

Who needs to "iterate" so quickly that several minutes added to your build time becomes a huge issue?

Re: 65535 interfaces ought to be enough for anybody

#70

Earlier quoted context omitted.

Why do people always talk about multidexing like it's such a nightmare? https://developer.android.com/studio/build/multidex.html It's really not that bad, It only gets a little squirrely if you're trying to support super old android versions.

Our app's build time ballooned by 2-3X or more when we went to multidex. We've had some luck reducing it, but we'd still like to axe multidex. I definitely consider a 3X build time increase (not 30 seconds to 90 seconds, but 1 or 2 min to 5-8) to be a significant problem, bordering on nightmare... especially since we just included a few more libraries that put us past the 65k mark. Is that what other people have seen…

How is your dev pipeline set up such that an 8 minute release build becomes such a problem?
Post reply on HN