multiple logins from same user

[pshaughn]

there are 3 cases when a user tries to connect:

• the same user already has an active controller
• the same user had a controller recently and that controller's instance's past horizon state hasn't caught up to when that controller quit
• there's no other controller for the user

the path of least resistance for API calls is not to worry about multiple connections:

• editing your avatar while logged in wouldn't take effect right away but wouldn't otherwise break anything; two conflicting; two conflicting avatar changes would settle on one or the other, again without otherwise breaking anything
• editing your password while logged in is harmless; of two conflicting password changes, one wouldn't be able to authenticate so there's no problem
• admin commands shouldn't care whether the admin is also playing the game at the time

while there is no a priori reason playsets must to limit controllers to one per user, it has advantages:

• if the instances wants to persist data on a per-user basis across connections, the model of that data can be simplified by assuming there won't be multiple controllers messing with it
• if the engine can promise more invariants to the playset, it's fewer cases for the playset to check
• allowing multiple logins with no complaint is counterintuitive to a user who forgot they had another tab open

A possible approach:

• controllers for which a login has passed authentication have three states, and there's a keyed-by-username collection for each state: inbox, live, and outbox
• another inbox or live controller for your name makes your new login fail
• just an outbox controller for your name makes your login create an inbox controller, send a bare pong with no game state, and not set a connection timeout.
• if there's no controller for your name, your login goes straight to live and connects to the instance
• a controller moves from live to outbox when it disconnects from its instance's broadcasts/when it sends a 'q' event (check if there's any situation where these two conditions aren't happening from the same event handler)
• a controller is deleted from outbox when its instance applies its 'q' event to the past horizon; as this happens, the inbox is checked, and the controller then goes to live and connects to the instance
• a controller is deleted from inbox if it disconnects while it's still there

[pshaughn]

client code flow is simpler if "bare pong with no game state" precedes the game state even if the connection is going straight to live (also if serializing and sending the initial game state is a bit expensive, sending the pong first is more accurate)

[pshaughn]

seems to be working, although scripted rapid-fire stress-tests on it might be a good idea later