lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [thread-next>] [day] [month] [year] [list]
Message-ID: <4D5EB2AE.5050703@genband.com>
Date:	Fri, 18 Feb 2011 11:55:58 -0600
From:	Chris Friesen <chris.friesen@...band.com>
To:	netdev@...r.kernel.org
Subject: how to listen() on single IP address but very many ports?


I have an application team that needs to listen() for tcp connections on
many ports (and by many I mean pretty much all 64K ports).  However, the
connections are short-lived, and the number of active connections at any
given time is small.

Apparently when they tried this before on an older kernel the
performance of the naive "open 60K sockets and call listen()" solution
was not acceptable, so they used NAT with port mapping to direct all the
incoming packets to a single real port.  However, they now want to add
support for IPv6 and this solution won't work.

What's the recommended method for efficiently listening on this many
ports?  Should I be able to efficiently listen() on that many sockets
using epoll or similar?  If there isn't a way to do this, is there an
equivalent IPv6 workaround?

One possible solution that came up was to implement a PORT_ANY which
would match any incoming request that didn't already have an explicit
listener.  Even better would be a way to bind a single listening socket
to a range of ports.

Has anyone ever considered something like this?

Chris

-- 
Chris Friesen
Software Developer
GENBAND
chris.friesen@...band.com
www.genband.com
--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ