I will check it out and send you a responce after this email about YOG.
The current system is YOG routed using TCP. Management of player and game lists is all done by YOG. During pre-game, YOG routes and updates information as settings and players change. During in game, all orders are sent to YOG, which distributes them to all the players. New system relies heavily on YOG, no P2P routing or connecting to the game host or anything. Hole punching isn't necessary since all players make out-going connections to YOG. A new system based on P2P, where all players connect to all players (or as many connections as possible), is planned, however YOG routing works great for the present game load.
I'll give you the full scoop on individual classes for the complete YOG experience, this is a bit long. I've taken a strongly devide and conquer strategy towards YOG design, all of the classes only perform a small part of the total system and are usually as self-contained as possible.
YOG is based on a simple message system between server and client.
The technical, low level:
The messages themselves are seen in NetMessage.h, each of them are self-serializing, self typing, and can self-format to a human readable form for low level parsing.
NetConnection is a basic wrapper over SDL connection, meant to abstract to a higher level to use the messages in NetMessage, and if needed, could be converted to multi-threaded without changing interface.
NetBroadcast uses UDP to send lan game info to all on the subnet (ip
255.255.255.255). NetBroadcastListener receives those packets and maintains a list of available lan games.
There are a few data classes, most notable YOGGameInfo, YOGPlayerInfo, YOGMessage, LANGameInfo, all of which are simply self-serializing, self formating classes that hold data and do nothing more, similar to the NetMessage described above.
All of the NetMessage hierarchy, the event hierarchies, and the IRC thread message hierarchy (discussed later) all have python scripts (add_x_.py) which allows one to quickly add in new ones of these simple types of classes. It makes it allot easier to maintain separate, self serializing self formating classes without it being tedious. The scripts use simple intelligent substitution, placing code at specific commented 'markers' in the files. See NetMessage.h line 83, "//type_append_marker" or line 1562, "//message_append_marker"
NetTestSuite is a simple test suite meant to make sure that all of the data classes, the basic self serializing classes like NetMessage and YOGGameInfo, work correctly, including serializing right. It needs to be updated for my most recent changes. It runs every time the YOG daemon starts, and provides a basic layer of assurance when bug testing YOG. Its proven useful more than once.
Client side:
YOGClient is the direct connection to the server, it handles connecting, logging in, manages the lists of available games, the list of YOG players, and distributes other messages to the various sub systems that handle them.
MultiplayerGame handles the managing a game client side, both for game host and game client, and both before and during the game. It keeps a global track of the game, including the GameHeader, MapHeader, the connected players, the currently set latency mode, and wraps functionality for kicking, changing team colors and adding AI's.
NetPlayerManager handles specifically managing the list of players in a consistent manner. Its the code that, say, when you add an AI, it actually adds it to the list of BasePlayer, and chooses the least-used team color to give to that AI. Its merely code that used to be sprawled out now packed into one.
NetEngine has the task of manging Orders during in-game, it slides recieved orders into queues locally, it tells when it has recieved enough orders to execute, it also handles order padding during online games (rather than sending 25 orders per second, sends and receives closer to 4, filling the rest in with null order 'padding'), and it handles order latency.
YOGChatChannel receives incoming messages for, and tracks the history of, a single chat channel, and handles outgoing chat channels as well. Right now we have a chat channel for the lobby, and more for each created game for the pre-game setup (in game uses different system for chat). In the future, we might have multiple lobbies, or private-chats, etc... so this architecture is nice.
All of these systems (except net engine, which doesn't talk to GUI) use a listener idiom to communicate to the GUI (MultiplayerGameEventListener, YOGEventListener, YOGChatListener), and YOGClient and MultiplayerGame use a hierarchy of events to communicate (MultiplayerGameEvent, YOGEvent).
IRC is done by the class IRC (the old school one you made), IRCTextMessageHandler (a facade wrapper class), and IRCThread and IRCThreadMessage, which deal directly with IRC, but in another thread. IRCTextMessageHandler deals with these.
MapAssembler has the job of sending and receiving maps through YOG, used when a player connects to the game and doesn't have the map. Basically just zips, sends, receives, unzips, sent through the same NetMessage system as anything else.
Server Side:
YOGGameServer is the main server class. It is kicked in by running `glob2 -daemon`, or when you run LAN. Handles logins and registers, lists of players and games, and just generally ties everything together.
YOGPlayer represents each player connected to the server. Does simple work like managing the state-machine when logging in, and calculating pings, distributes all received messages to their appropriate sub systems, and manages the game and player lists as the player sees them, sending updates when it needs to when the players list and the actual list on the server differ.
YOGPasswordRegistry manages the password-user name combinations, including flushing the password file, and hashing the passwords server end.
YOGChatChannelManager manages the list of chat channels, allocating ID's for new chat channels.
YOGServerChatChannel represents a single chat channel on the server end, including all players who are signed up to that channel, and manages distributing messages to all signed up players.
YOGGame represents a game on the server end. It maintains the list of players, automatically (un)subscribes them to the game chat channel as the come and go, keeps the map and game headers, chooses the latency mode (slower connections, more latency adjustment), manages when the game starts (host requests game start, it authorizes or un-authorizes it), and manages which players are ready to start and not.
YOGMapDistributor is attached to a YOGGame. It manages sending the map to all the players who don't have it by storing map chunks, requesting more chunks of data from the host, and sending chunks of data when their requested by clients.