[HN Gopher] How to stop running out of ephemeral ports and love ... ___________________________________________________________________ How to stop running out of ephemeral ports and love long-lived connections Author : pimterry Score : 45 points Date : 2022-02-02 18:27 UTC (1 days ago) (HTM) web link (blog.cloudflare.com) (TXT) w3m dump (blog.cloudflare.com) | nhoughto wrote: | 28000 ephemeral ports is enough for the c10k problem, but 100k+ | seems a stretch. At what point is increasing the number of ports | from 28k to a higher number the right answer? Reuse as described | here sounds like a useful optimization but at some point (or due | to pathological workload) even that will be exhausted I'd think? | What to do then | toast0 wrote: | > At what point is increasing the number of ports from 28k to a | higher number the right answer? | | You can increase it to 65535, although you'll get funny looks | from some people. Beyond that, you'd need TCP and UDP | extensions, which seems unlikely to be deployed. Usually it's | OK, you rarely need to connect more than 65,000 times to a | single host; but if you do, you can try to convince them to | open more listening ports, or use more listening IPs or more | connecting IPs --- one way to encourage IPv6. | | Really, the socket API should be updated to a single syscall | that binds and connects (or listens) and lets you express what | you actually need. Whether it's to have a whole port reserved, | or just need a currently unique 4-tuple with no local | information selection, or you've got one piece of the local | information; or maybe you want a connection that will hash to | the same CPU you're currently on. If you control all of the | outgoing connections, you can do this work in userspace, but | it's challenging; if you're running multiple processes that | share the 4-tuple address space, it's a lot harder (PS, try to | partition the space so processes don't compete). Turning two | (or more) syscalls into a single one is useful anyway, | especially if you've got meltdown mitigations turned on. | uberduper wrote: | Additional IPs on the interface to use as a source. | 0xbadcafebee wrote: | Just one more reason to redesign the tcp/ip stack. Can you | imagine what our ABIs will look like if we're still hacking in | kludges for another 40+ years? Opening a connection "the right | way" will look like casting a spell with voodoo. Ooh, maybe we'll | get cooler titles then, like Master of the Dark Network Arts. | dragontamer wrote: | Is this really a tcp/ip stack issue, or is this a BSD-sockets | issue? | | Since Cloudflare showed off how it is fixed with another API | (aka: connectx) and/or ordering of bind/connect/etc. etc., it | sounds more like a BSD-socket issue to me. | | ------ | | In fact, the closest thing to a "protocol error" to me is in | the UDP section as far as I'm concerned? ___________________________________________________________________ (page generated 2022-02-03 23:00 UTC)