6 ms·
Hardware/Network guy here. I realize this thread is probably only tangentially appropriate for this discussion, but I digress, I haven't seen anything too close
by noobface 14y ago
Hardware/Network guy here. I realize this thread is probably only tangentially appropriate for this discussion, but I digress, I haven't seen anything too close in my daily visits here.
There's a ton to be said for per-thread connections. This author certainly recognizes the benefit of truly parallel communications, however, there are some networking considerations that might be of interest. Especially regarding the tendency to simply "open more sockets" to increase overall speed.
Most software guys I know tend to ignore or just be ignorant of how their choices affect the underlying hardware. I realize this is a brash generalization; there are some full-spectrum people out there, and I appreciate you.
That said, opening new sockets is not without diminishing returns. The sheer volume of port numbers for those sockets can lead to memory exhaustion in consumer network devices, especially when something else is running. In this respect, bit torrent is atypically aggressive.
Basic consumer routers have hard time keeping up with their internal processes when flooded with new TCP sessions for hundreds/thousands of ports. NAT tends to run slowly as memory exhaustion takes hold and many times the only option is to shorten the timeout window on connections. (Admittedly, the default settings for NAT table timeouts is ridiculous; sometimes up to 300 seconds). With long default timeouts, it's no wonder these simple MIPS systems are overwhelmed.
Count how many tabs you have open now, and consider that they all may be using the same number of ports the services you're building do. Not to mention the ad networks...etc
All I'm really trying to get across is, more ports, especially on consumer devices, does have diminishing returns despite its apparent immediate benefit.
Yes, newer routers do have better hardware. Yes, your AWS machine can handle tons of connections. But your end users may be like you, they may not know how much memory their local router has or particularly care.
I'm not advocating anything other than moderation the number of sockets you employ. I just wanted to get this out there.
- jlouis 14y agoNAT (Or more correctly PAT) was never a good idea and this is the main reason why the cheap network device suffer. It should not need any kind of intelligence. When some of us "Software" guys are up in arms over the slow IPv6 adoption it is because the current IPv4 state translates to thousands of extra code lines for little to no benefit. We also need those cheap consumer devices to understand Active Queue Management, but that is another problem :)
- dsl 14y agoHaving seen the "sausage factory" of consumer gateway devices myself, I can tell you the problem is not NAT or any other technology you'd like to blame. The specs are written by non-technical product managers in the US, a contractor in Taiwan selects the OEM boards that most closely fit the spec requirements, pieces are combined and packaged in China with firmware outsourced to a completely different company in South Korea working off the OEM specs not the designs of the final product. (none of this is an exaggeration and is an example from a major broadband router maker) They literally don't know if a feature works enough to print on the box until the first batch is unloaded off the boat.
- noobface 14y agoHeh. You've seen what I've seen.
- meaty 14y agoSounds like Thompson or whoever they are called this week.
- jlouis 14y agoI don't doubt you, but my comment there was not directed at the CPE device. Rather for the code inside the program (on the PC endpoint) which has to deal with breaking through NAT.
- ishbits 14y agoMore correctly, NAPT is what is most commonly used, but often referred to as NAT. Just being picky as I've implemented just NAT, just PAT, and NAPT before.
- aidenn0 14y agoExcept we will still need stateful firewalls in consumer devices with ipv6, and that's just as hard to get right as NAT.
- dsl 14y agoI think you might be a bit confused here. The point of a server (http, gopher, or otherwise) is to serve as many clients fully as possible as quickly as possible. What you are talking about appears to be making lots of outbound connections from a client side application, which I think most people know is bad. Or are you suggesting you've been burned by putting servers behind consumer grade routing and switching equipment?
- noobface 14y agoLike I said initially, my concern is only tangentially related to the server stack. Oh I'm not advocating serving less clients at the server or even limiting the sockets available at the server. It's purely a critique of the number of sockets per client. Not the overall number of sockets the server supports.