Sanctimonia: Bulletproof Networking

In a comment on the most recent Rather Infrequent Open Thread, Sanctimonia announced that he had made significant progress with network transaction handling in his Ultima-inspired multiplayer online game engine, Sanctimonia:

Also, since this is the RIOT, I got “bulletproof networking” working and thoroughly tested tonight. No transactions are lost, ever, and they’re always processed in sequence even if received out of sequence. That goes for all clients and the server. I control the timeout, of course. Yay for a fundamental building block of an MMO being so damn solidly implemented. Next is server persistence, which consists of approving/denying all client requests and permanently committing them to the game state (data files). Go me.

Bit by bit, another fine project gets that much closer to a much-anticipated release. Good show, Sanctimonia!

7 Responses

  1. fearyourself says:

    Congrats!! How many clients did you try at the same time?

    Jc

  2. Iceblade says:

    Excellent work Sanctimonia.

    I’m loving all of this project news that’s been coming up recently.

  3. Sanctimonia says:

    @ Jc: Thanks. Interestingly it wasn’t the number of clients that caused the problem, but some weirdness with the server sending multiple UDP packets back-to-back causing one or more of them to be lost. It was tested over a local loopback interface (I guess that’s what you’d call it), as I run the client on bare metal and the server on a VM with static IP on said BM.

    My guess, knowing nothing about networking, is that UDP is inherently shitty and machine-gunning packets even over loopback results in dropped packets. My crappy old workaround was to force the server to halt execution for 200 ms after every packet sent. My recent modification, adding a transaction queue history for the client and server whose transactions require acknowledgment within x seconds, gets around those inevitably dropped packets.

    I assume in a real-world scenario over the Internet, when packets are lost due to God-only-knows type reasons, this will prove invaluable. The simplicity of the solution is what makes me excited, as I don’t foresee having to touch that code again.

    As far as testing multiple, clients, I’ve so far tested two on computers in the same room and it works very well. I’m open to testing a shitload of clients simultaneously, but need to find enough people and forward the port on my router to make the server publicly accessible.

    @ Iceblade: Thanks, and me too. WtF has really been spot on with project news lately. I dig the news about BioWare/Mythic and all, but we grunts on the ground are what keep the gears turning.

    @ No one in particular: Tonight I got player persistence working. All player variables are saved to file every 10 seconds and when the server closes. When the server is run, all player data is loaded into the array of structures defining the player base and player authentication attempts are verified against it. Once authenticated existing players are fed their saved data so they start in the same state.

    No offline AI yet, but I’m getting close. Before that I’m going to do the vegetation trampling thing and server approval/denial of client actions.

    • WtF Dragon says:

      Sanctimonia:

      WtF has really been spot on with project news lately.

      Would that it were so! I’m mostly keeping up, but there is a backlog of stuff I still need to report on.

      Still, thanks…it’s nice to hear that I’m not letting people down overmuch.

      I dig the news about BioWare/Mythic and all, but we grunts on the ground are what keep the gears turning.

      True dat.

  4. fearyourself says:

    UDP is known for losing packets. That’s the point it is fast but you lose info. Normally in your kind of game you have both UDP and TCP.

    UDP handles anything not important if lost: positions, terrain updates, etc. Because if you lose such a packet, you’ll statistically get the next one.

    TCP: for important ones: an object got picked up, an attack, etc.

    You send most via UDP to keep the layer light.
    Jc

  5. Sanctimonia says:

    @ WtF: Well, you got my news up and I felt pretty damn good about it. You’ve also had a lot of other project news and that makes my day as well. There’s only so many AAA skull knockings I can take around here, so all of that is welcome relief.

    @ FearYourself: That is a nice idea, combining the two. Eventually I’ll test this thing over the Internet and gather some metrics about how many packets are lost to see if it’s worth using both protocols. Performance is my utmost concern, but reliability is right on it’s ass.

    @ No one in particular again: Vegetation trampling now works! I set it up (as a test) to kill 100 inches of vegetation wherever players walk. The server permanently commits it to the landscape vegetation layer data file and sends it out to players when they require new cell data. It doesn’t show immediate results (unlike plant growth’s immediate feedback, which will be removed), so you have to walk out of the cell and back to see the new path. Outside of testing it will only remove one inch of vegetation rather than 100, so it will take multiple tramplings to reveal the soil beneath. Also the vegetation doesn’t grow back yet which is shitty. I’ll put up a proof-of-concept video in a moment.