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