Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

65535 interfaces ought to be enough for anybody

aakinshin.net

Post reply on HN
Print view View original

51–60 of 82 posts

Re: 65535 interfaces ought to be enough for anybody

#51

Post by phicoh »

alcari wrote: post #42
cjensen wrote: post #41

Earlier quoted context omitted.

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. [1] https://en.wikipedia.org/wiki/Portmap

As an alternative, predating Portmap by around 700 RFCs: tcpmux[0]. Everything connects to port 1 and asks for services by name. [0]: https://tools.ietf.org/html/rfc1078

I have an experimental protocol that uses tcpmux. Works very well for that purpose.

However, it sort of requires your service to be started by inetd. It doesn't work for services that want to manage their own listen queues.

It also complicates firewalls. It makes it much harder to have rules that vary per service.

Re: 65535 interfaces ought to be enough for anybody

#52

Post by munificent »

to3m wrote: post #12

Any time you have a 16-bit count, it won't be enough. It's a dangerous size...

You're succumbing to selection bias[1]. You never notices all of the 16-bit counts in all of the software you use that don't overflow. For all we know, there could be a thousand of them for every case where 16 bits is too low.

[1]: https://en.wikipedia.org/wiki/Selection_bias

Re: 65535 interfaces ought to be enough for anybody

#53

Post by surye »

recursive wrote: post #43
StringEpsilon wrote: post #32

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.

Why not? Is having zero interfaces not distinct from having one interface?

Re: 65535 interfaces ought to be enough for anybody

#54

Post by karmelapple »

Benjammer wrote: post #19
throwawayish wrote: post #11

Earlier quoted context omitted.

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

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?

Re: 65535 interfaces ought to be enough for anybody

#55

Post by revelation »

overgard wrote: post #37
sixothree wrote: post #25

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.

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.

Re: 65535 interfaces ought to be enough for anybody

#56

Post by vkou »

d33 wrote: post #13
throwawayish wrote: post #11

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?

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.

Re: 65535 interfaces ought to be enough for anybody

#57

Post by dgfgfdagasdfgfa »

karmelapple wrote: post #54
Benjammer wrote: post #19

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…

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

Re: 65535 interfaces ought to be enough for anybody

#58

Post by orbitur »

dgfgfdagasdfgfa wrote: post #57
karmelapple wrote: post #54

Earlier quoted context omitted.

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…

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.

Re: 65535 interfaces ought to be enough for anybody

#59

Post by recursive »

surye wrote: post #53
recursive wrote: post #43

Earlier quoted context omitted.

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

Why not? Is having zero interfaces not distinct from having one interface?

It is. But when you have one interface, that interface can be given the number 0. So you have a total of 1 interface, even though you've only counted up to 0.

Edit: I misunderstood. I'll leave the comment up. But I originally interpreted the story as meaning that each interface needed to be assigned an unsigned 16-bit id, which allows for a total of 65536. That was just inference on my part though. It literally says that more than 65535 are not allowed.

Re: 65535 interfaces ought to be enough for anybody

#60

Post by monocasa »

vkou wrote: post #56
d33 wrote: post #13

Earlier quoted context omitted.

Are there any legitimate use cases for that many methods?

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?
Post reply on HN