I am building both an engine and a networked game at once because I'm completely insane. The original design/plan was to use internal Unix sockets for each "zone" for server<->zone communication, with UDP for server<->client(s) communication.

My conundrum is this: It seems like there are a variety of ways to handle getting packets from a client to the intended "zone", not none of them seem particularly efficient.

  1. Simply move data from a singular queue to the intended zone server, via data objects within code. (Pro: Simple // Con: Potentially slow as molasses in a Canadian winter.)
  2. (Somehow) Allow Server and Zones to communicate via Unix sockets, with a networking class/wrapper to pass packets into a "pool" for redistribution to Zones. (Pro: Unix sockets, from my reading, tend to be fairly quick. // Con: Need to re-evaluate how I am currently handling packets and the redistribution of packets makes it too similar to #1 for my liking.)
  3. Use the underlying messages system on Linux. Ref (Pro: Crazy fast for large objects. // Con: No idea how to implement at the moment.)

Additionally, if there is a specific text, document, or book(s) that I should be hitting instead of harassing everyone here, PLEASE let me know! Not at all afraid to spend a week tearing through a 200+ page tome.

Thank You!

  • 2
    \$\begingroup\$ Haha, +1 for self-awareness :) I'm not quite clear on what you're lookig for, though -- what exactly is a "zone", and why does it have to be separated from the server process? Is it a lobby-vs-gameroom kind of deal? \$\endgroup\$
    – Quentin
    Commented Sep 25, 2017 at 7:50
  • \$\begingroup\$ @Quentin, in logically forming the answer to your question, I believe I answered my own. A zone ( or level/map ) is a separate process that can safely "crash" without bringing an entire game server down. If the zone for "Scaryface Mountains" (lol) crashes, the entire server doesn't go with it. Specifically, the server process catches the failure and starts up the zone bootup for the now-dead process. \$\endgroup\$
    – Beau B.
    Commented Sep 25, 2017 at 15:05

1 Answer 1


Thanks to Quentin's question, I believe my path to success is actually to utilize each "zone" as a separate process, not embedded into the main game. This means I can use Unix sockets (Berkeley Sockets) to communicate between the world server and the zone servers. While the builtin message queue looks promising, the numerous mentions of it being less than ideal for simple/small packets (i.e. movement update with 2 floats, 1 uint32, and 1 string could actually be slower than a simple Unix-socket sent datagram/payload).

@Quentin, thank you again!

  • \$\begingroup\$ Well then, you're welcome :p \$\endgroup\$
    – Quentin
    Commented Sep 26, 2017 at 10:55

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .