4 ms·

As they say: is that a lot?

by romed 8y ago

kbenson 8y ago
Well, if it's TCP/UDP connections, there's only 65k ports available to assign, so it would be all the ports. That's a lot of ports, but I'm not sure why it's supposed to be particularly hard. Off to read the article now... Edit: As masklin referenced in reply to me[1] that jsnell pointed out, that's the ports for a single IP. So yeah, it's not all the ports, but it is all the ports for a single source IP, unless I'm missing something. You can of course assign multiple source IPs to extend this, but it is a limit to be dealt with. 1: And then deleted it, at least as of now, even though I think it was a good point.
- deleted 8y ago
  [deleted]
- 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 ago
    Yes, 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]
PopeDotNinja 8y ago
As they say: it depends :) . Practically speaking, think of it this way... Total computer power - Cost of maintaining sockets = Available computer power to use sockets. If total computer power - cost of maintaining sockets is close to 0, there's nothing one can really do with those sockets. If the system has 65K sockets open is it's barely breaking a sweat, you can still do plenty of work!

As they say: is that a lot?

by romed 8y ago

As they say: is that a lot?

Well, if it's TCP/UDP connections, there's only 65k ports available to assign, so it would be all the ports. That's a lot of ports, but I'm not sure why it's supposed to be particularly hard. Off to read the article now... Edit: As masklin referenced in reply to me[1] that jsnell pointed out, that's the ports for a single IP. So yeah, it's not all the ports, but it is all the ports for a single source IP, unless I'm missing something. You can of course assign multiple source IPs to extend this, but it is a limit to be dealt with. 1: And then deleted it, at least as of now, even though I think it was a good point.

deleted 8y ago
[deleted]
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 ago
  Yes, 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]

PopeDotNinja 8y ago

As they say: it depends :) . Practically speaking, think of it this way... Total computer power - Cost of maintaining sockets = Available computer power to use sockets. If total computer power - cost of maintaining sockets is close to 0, there's nothing one can really do with those sockets. If the system has 65K sockets open is it's barely breaking a sweat, you can still do plenty of work!