I worked on this for a bit longer than I thought I was going to, but I've also got a sturdier product than I was expecting to have at this stage.

I've pushed all my work to Github; here is a permalink to the exact point I'm at currently, regardless of what future work I do.

So, let's see what it can do! We'll run ./server.py in one tmux window and telnet localhost 8001 in two others.

I'm running ./server.py in the left-hand frame.

When I run telnet localhost 8001 in the upper-right frame, the server outputs a debug message to let me know that an anonymous user has connected. The user gets prompted for their name, after the usual Telnet guff.

I enter my name, and the server records that my connection has been 'registered'. It also lets the user know how many people are online currently.

I can now type 'commands', and they'll be passed along to my gamesession's eval-loop: of course, this isn't implemented yet, so for now it just gives us some server output to let us know it's been pushed through the queue and handled on the other end.

I'm creating a new connection to the server in the lower-right tmux window, using the same method as before.

Again, as before, I enter a username for myself (I forgot to add underscores into the regex for valid usernames!). Notice that all the username validation is server-side, and that the "people online" counter has incremented.

This is showing us a potential slip-up: even though the gamesessions for "bede" and "secondbede" are completely separate, they're using the same call() function. We'll have to be careful to make that call() call (heh) more specific: possibly by storing the game-state in the gamesession, and passing it to call() every time; or possibly by making call() a method of gamesession. (That second one would be more convenient, but call() would have to be renamed to something like call_cmd()- reasoning-wise, it's not gamesession that's being called, it's the command from the cmd_queue).

"bede" hasn't lost the right to request command-evaluation just because there's another player online.

Closing the first connection client-side.

Closing the second connection client-side.

Shutting the server down with C-c. This is strange - even with a "GameSession.running" signal value, it seemed like C-c had no effect, as if a thread was still running. Setting thread_name.daemon = True seemed to fix the problem, and accordingly it's in the current version, but I'm not quite sure what it does - let's hope it doesn't just leave threads running in the background, as the name seems to suggest.