3 ms·
I think you're confused about network programming in general. In a post like this, the assumption is that the concurrency is happening over a single network int
by anothergoogler 8y ago
I think you're confused about network programming in general. In a post like this, the assumption is that the concurrency is happening over a single network interface. It doesn't matter really. The most conspicuous limiting factor on a POSIX-compliant system is the number of available file descriptors. When you listen() on an address and accept() a connection, the networking stack allocates a file descriptor for that connection. Then you can handle more connections.
http://pubs.opengroup.org/onlinepubs/9699919799/functions/accept.html http://pubs.opengroup.org/onlinepubs/9699919799/functions/ac...
http://pubs.opengroup.org/onlinepubs/9699919799/functions/listen.html http://pubs.opengroup.org/onlinepubs/9699919799/functions/li...
Beej's guide is a popular intro, but I'd bet any text on network programming covers sockets.
https://beej.us/guide/bgnet/ https://beej.us/guide/bgnet/
- kbenson 8y agoYes, I was actually mistaken in assuming a server would use a port only once per IP for all connections, and not just once per client IP (and even farther, client IP and client port combo). It makes much more sense, and in fact I'd been pondering that since I commented as how that could work in practice with servers that actually keep connections open but can handle a lot of requests wasn't obvious in my prior mental model. > Beej's guide is a popular intro, but I'd bet any text on network programming covers sockets. I highly suspect I knew this at some point, but forgot it over the past 15-20 years since it didn't have direct relevance to most of my projects since that time. :/
- deleted 8y ago[deleted]