First note about socket layouts



About Notes

I was thinking it’d be cool to have a list of short-form notes about the things I’ve been working on. I don’t think they’ll be too structured, and I’ll probably limit myself to having one note per day. Inside each note I might have subsections about the different things that I did and then hopefully the title will capture something searchable that I can use to lookup old problems that I’ve already worked on or solved.

I’m not going to be too detailed for the average reader, this is mostly for me; but you might find some of them interesting too.

Socket layouts

During my stream today, I was investigating how organize sockets for my MMO learning project. I was trying to figure out how to merge nanomsg/mangos patterns into how my servers were setup. I ended up deciding that none of the patterns really fit with how I wanted to organize my server layout. See below:
Figure 1: Me figuring out how to organize sockets

I came to the conclusion, that I’d be better off just using regular TCP sockets to communicate between servers. I will probably have to come up with some abstraction on top of them that fits with how I want to organize my networking, and I’ll likely be very inspired by mangos. At a high level, I think I’ll organize like this:

  1. Game servers communicate by hosting a TCP socket which lets others “subscribe” to them. But the subscription is region based so that the subscriber can designate what data they want to receive. This is different from how mangos works because mangos PubSub sends messages to ALL subscribers (which I think is a bandwidth waste)
  2. Proxies likely don’t communicate with eachother
  3. Proxies communicate in two different ways:
    1. GameServer -> Proxy -> Client: GameServer wants to send a message to a user, so it tracks which proxy the user is connected via and sends the update there. The proxy receives and looks up the users’s client socket based on their userId. Then the proxy forwards the message to them.
    2. Client -> Proxy -> GameServer: The client sends a message to the proxy (e.g. I just pressed the up key!). The proxy tracks the game server that the player is currently on based on the player’s last known position. The proxy forwards the message to that game server.

There are definitely some things I haven’t thought through fully, but I think this is how I’ll start:

  1. GameServer hosts TCP listener which lets other GameServers subscribe
  2. GameServer hosts TCP listener which lets proxies connect
  3. Proxies dial to all GameServers
  4. Proxies host a server which lets users connect
  5. Users connect to random proxies (or are maybe loadbalanced?)