Lobby mode

[narc0tiq]

Details to be written at http://wiki.narc.ro/a/Guns_Server_Design

Briefly: lobby server is always listening, even while a battle is running, though will not allow new players to join a battle-in-progress (except to observe). Its primary function is to ensure all players have all other players' tanks' shape data, as well as (if necessary) the map data.

[narc0tiq]

Things the lobby needs to do:

• make up teams
• let players chat with each other
• set up the tokens for battle mode to auth players
• (eventually) authenticate players with the master server, to verify they're who they say they are
• synchronize tanks so all players can see each other correctly
• send maps (seed + diffs from seed) so all players can see the map correctly

[narc0tiq]

So, commit 90e6b77b168f82e9305efe7ebe9bfa00fdf946ad just implemented a seemingly functional lobby listener; so far, so good.

[Ethrel]

Alright. Well, I have my son this weekend, so I'll hit the client side and try to get some of that sorted out (and figure out PGU while I'm at it I suppose) next week.

[narc0tiq]

Sounds good, but try starting with just the chat part, which the lobby server already kind of does all by itself (not the way the protocol says, but it does do it).

I'll have to look at it in ugly detail to figure out what the full lobby protocol should look like, and I'm not convinced I'll get to that in reasonable time.

[Ethrel]

Yeah, that's what I was thinking.

Start with the chat, and if I figure that out in a reasonable time-frame, attempt to migrate over the protocols already implemented in battle server that should be in the lobby. And then look at the rest of the lobby functionality.

[Ethrel]

Ok. So as you saw, I started playing around with it. Rather than start with chat, I started playing with moving all of those protocol changes that were currently implemented in battle server over to lobby server. And I just wanna say, explicitly and for the record, I hate threads. That said, if we could come up with a nice and simple way to talk back and forth between the servers, that would be awesome, and I would be forever indebted. Even something like a faux socket between threads to easily pipe through edicomm commands would be awesome. Because I hate threads.

[narc0tiq]

Well, I ended up using a Queue for passing stuff out of the command line thread, so I intend to do something similar for passing stuff out of the lobby listener thread (with even less synchronization trouble, since TCP can just keep listening and the main thread can figure things out and pull from the Queue at its own pace).

Threads are pretty awesome in and of themselves, but the extra layers of indirection can get a bit irritating sometimes.

On an unrelated note, sorry I haven't been working much on anything lately, I've been mildly sickish and not terribly social this week.

[Ethrel]

Ok. So I have a commit ready with the queue into battle working. It has not been pushed yet, because I plan on squashing it locally when I'm it's all in. But I ran into a problem:

Battle server needs to be able to talk to lobby server. And with the asyncore loop locking the thread, I can't figure out where to implement the check on the queue into the lobby server. Or how. I toyed around with adding a queue object of some form to the asyncore map to include it in that loop, but it attempts to run socket commands when it polls. So as far as I can tell, without a REALLY hackish workaround, that is not an option (the really hacky workaround would be packaging our own re-written asyncore.py to allow us to do that), and I can't think of any other way to do it with the asyncore loop tying up the thread.

Ideas would be MORE than welcome as I just spend nearly 4 hours attempting to get the lobby server to actually respond to the queue.

[narc0tiq]

@Ethrel You should never need to do anything in the lobby's secondary thread -- that thread is specifically dedicated to running the asyncore loop, and we never need to bug it.

To talk to a lobby connection from outside the context of another lobby connection, we need to get a handle on the connection we want to talk to, and push data into its fifo -- what this equates to is that we need to keep the player list accessible in the main thread, which is a complete unknown to me in terms of thread-safety.

Of course, we can drop asyncore/asynchat altogether and do our own select.select() calls, but I'm sure there's a non-hackish way of doing this in our current implementation.

[narc0tiq]

@Ethrel have a look at narc0tiq/guns-game@6d3296a44b172bf9e969c0aed124a493a49b1169 for what I did to implement a simple "say" console command that reaches out to the lobby server and pokes everyone.

Now, this really isn't thread-safe at all (needs a threading.Lock or something), but it does show how to reach out to people on TCP streams.

As an immediate todo for myself (that I'll be looking at shortly), I need to flesh out the lobby protocol and make some kind of mapping from lobby players to battle players and back (probably via token, which needs to be assigned by lobby). In that order, most likely.

Something for the client: client needs to initially talk to lobby and auth (using not-yet-existant protocol) and get a token, with which it should then authenticate to the battle server.

[Ethrel]

Ok. I kinda see what should be done here. And I think I see a workable solution. Gimme a couple hours to play around and test out some stuff and we'll see what I come up with.

BTW, the reason I was looking at passing stuff into lobbyserv was me attempting to map lobby/battle players -- specifically in the case of chat, which is in the protocol as MSG , meaning the lobby actually needs the id of the player. Now, as of writing this section, I realize that lobby should be assigning pid's in the first place. Really, I need to stop trying to code while tired.

[Ethrel]

Started implementing at bef4d936bb6eae7762ecfd7d11c5685e53010eaa

If there's any problems so far, you know what to do :P

[narc0tiq]

@Ethrel -- Yes, I know what to do, which is to talk to you, post comments, etc. :P

I just had the thought that it would be very nice to keep bullseyestudio/guns-game/master mostly stable (bugfixes only) and use branches for new dev (like working on the lobby), so I'm going to try to rewrite history a little to do that (and then I can murder my fork at narc0tiq/guns-game).

[Ethrel]

okies. Sounds good.