5 ms·
Let me try. You could expect that on linux host you can have 64K concurrent connections to single target ip. If you had two target ips you could expect 128k con
by majke 4y ago
Let me try. You could expect that on linux host you can have 64K concurrent connections to single target ip. If you had two target ips you could expect 128k concurrent conns.
This is not how it works.
Especially when doing bind-before-connect trick to set source ip.
Linux internally tracks local ports in a hashtable and often forbids their reuse in surprising ways.
The most surprising is ordering. If you do bind-before-connect then on that port later connect() will not work.
The effect is that its very hard to achieve the 128k conncurrent in our two targets scenario
- toast0 4y agoI've done similar exercises with FreeBSD. The tldr is, if you want to approach the connection limits[1], you need to use bind-before-connect for the bulk connections, and it's useful to have connect on a separate (small) port range, for the ancillary connections your machine might have. There's lots of other things you might want to do, such as divide your outgoing ports by thread/cpu so there's no conflicts; and if you're dividing by cpu, you should probably calculate the recieve side scaling (RSS) hash, most likely Toeplitz of the returning packets, so you work the socket from userspace on the same CPU it's going to be worked in kernelspace when it comes in. Modern FreeBSD and presumably Linux are very good at scaling inbound connections, but if you need to scale outbound connections, you've got to do more of the work. [1] Also, consider if you're in the client seat, you're more likely to be the one closing the connections, so you've got TIME_WAIT states on your side; depending on your rate of connection closing, you may have a significant number of those, clogging up your ports; or it may not be significant at all.