Slashdot Mirror

← Back to Stories (view on slashdot.org)

Breaking Down the Demigod Launch

Posted by Soulskill on from the win-some-lose-some dept.

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.

4 of 70 comments (clear)

  1. Failure to build in an idiot margin by chrylis · · Score: 3, Insightful

    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.

  2. No Stress Testing?? by WeekendKruzr · · Score: 4, Insightful

    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.

    1. Re:No Stress Testing?? by Anonymous Coward · · Score: 1, Insightful

      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.

      One has to put it in perspective. One "amateur" mistake can easily be one "damn it, this shit isn't working but my balding, out of touch manager is insisting on creating unrealistic timetables for our application" mistake.

  3. This is why I wish we could start using IPv6 by JSBiff · · Score: 2, Insightful

    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).