Slashdot Mirror
Breaking Down the Demigod Launch
In addition to the piracy troubles that plagued Demigod's launch (and partly exacerbated by them), Stardock and Gas Powered Games ran into severe networking issues that hampered their ability to accommodate players with a legitimately purchased copy of the game. Brad Wardell has now posted a frank, detailed explanation of what happened and how they dealt with it. Quoting:
"Demigod's connectivity problems have basically boiled down to 1 bad design decision and 1 architectural limitation. The bad design decision was made in December of 2008 when it was decided to have the network library hand off sockets to Demigod proper. In most games, the connection between players is handled purely by one source. ... So in Demigod, on launch day, Alice would host a game. Tom would be connected to Alice by the network library and then that socket would be handed to Demigod. Then, Alice and Tom would open a new socket to listen for more players to join in. As a result, a user might end up using a half dozen ports and sockets which some routers didn't like and it just made things incredibly complex to connect people and put a lot of strain on the servers to manage all those connections.
Yes, this probably could have been handled better, but many home NAT boxes are so broken that they ought to be recalled. I'm actually a bit surprised that there's not a WRT54GL equivalent with well-behaved 2.6 wireless drivers that ships with an open-source configuration interface; it seems that it'd be cheaper than constantly reinventing the wheel.
I am pretty sure the peer to peer nature of torrents, that require connections to multiple people to get good speed, makes multiple sockets mandatory.
Troll is not a replacement for I disagree.
BitTorrent has similar issues. You'd have thought they'd realise that multiple sockets = fail for most home network equipment.
What are you talking about? AFAIK my torrent client uses one port only. And as with any P2P protocol, the only issue is to allow/enable/kicktherouterinto incoming connections. And if Grandpa can't set up NAT, he's not going to be a full member of the herd, and there's nothing we can do about it.
How did they not perform any simulations or trial runs with players connecting out over the internet in order to stress test this? If they did, how could their testing not notice that routers in general don't like large numbers of listening sockets on it's clients? This is a serious amateur mistake.
I've done just that. Passthru of BT port to my PC, and it still shits itself with any more than about 20 peers.
I eventually manually limited BT to 10 peers total, which essentially made it pointless to use. All because my router couldn't handle the packet load.
Note that downloading ISOs using a multi-part download resuming app to saturate my downtream from one source does not cause this issue. It's P2P-specific.
Finally had enough. Come see us over at https://soylentnews.org/
Never had any performance related issues, even on the 24Mbps I had back in Sweden. The homebrew debian firewall can be replaced with m0n0wall, pf sense or similar if you prefer web based administration.
I found a fast warez site: http://warez.it.kth.se
I know, beating a dead horse here. . .
The idea of P2P connections between members of a multiplayer game seems like pretty much a no-brainer, but because of NAT, it's a total P.I.T.A. Everyone likes to say, "We don't need IPv6, just use NAT". But, NAT makes lots of things more complicated (like needing to setup port-forwarding to accept in-bound connections, or using a third-party server that isn't behind a NAT that everyone makes an outbound connection to). Plus, port forwarding sucks because only one computer per network can have any given port forwarded to it (that is, you *CAN* forward different ports to different computers, say have port 5000 forwarded to 192.168.1.10, and have port 5001 forwarded to 192.168.1.11, but you can't forward port 5000 to both computers - but if they each had their own unique, public IP, they can both receive traffic on the same port).
I long for an IPv6 world where NAT is basically a thing of the past (and for those who say NAT is good for security, there's no reason you can't still have firewalls built into routers).
Who would have thought that routers might not allow for large numbers of listening sockets on its client machines?
I wouldn't have. I've dealt with pretty good equipment my whole life because I love computers and am willing to buy nice equipment. The people who don't love computers and don't buy that equipment don't tend to use it like I do anyway, so I've never encountered this in my informal tech support either.
these devs apparently didn't consider these obvious questions. Do they even have a QA department?
That's quite a leap there. What you consider an obvious question after reading the summary doesn't seem so obvious in a vacuum when you have the entire rest of the game to consider as well. It's nearly impossible to consider everything you need to consider while programming because there are so many variables involved. QA can't catch everything because QA's not going to try the game in as many ways as home users will. QA catches the most obvious and glaring bugs, but they can't catch everything that 1m+ users will.
The bottom line is that, while programming their game, they had a bug. In this case, the bug was right smack dab in the middle of the most important part of their game. They should have never let the bug get into production (just like no bug should ever get into production), but to say that it was obvious is going a little far.