-
Notifications
You must be signed in to change notification settings - Fork 130
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Improve player connection and disconnection logic #258
Improve player connection and disconnection logic #258
Conversation
Break eventstore into stateful sub objects, clearEventStore method for management.
pending connection destroyed: error path for clients that fail to connect, required to cleanup connection state in this error case. client-connected: Supersedes steamid connected, use base unreal engine client flow. Removes dependancy on EAC (broken as of squad 3.4). First step in resolving a new client connection. this gets us a connection id, steamid. client-login: 2nd step in player connected flow, this setups the steamid into eventstore.steamid-connected. playercontroller connected: gets us player controller. used in player connected flow. player-connected: update to use new eventStore layout, now all players should always have suffix,steamid,controller. These are now also cached within the logparser for lookup. last step in player connected flow. player-disconnected: uses new eventStore layout, marks players in eventStore.disconnected but doesn't remove cached players till map change; may be needed in cases with delayed logs, needs further testing. Broken as of Squad 3.4 due to EAC changes steamid-connected: Removed in favor of client-connected, no longer works as of squad 3.4 due to EAC changes.
Gist of the new player connection flow, I understand its hard to follow. Client Connected appears when a new network connection is made, and contains the steamid. We set this in eventstore.clients. These events are asyncronous from clients resolving. There is an error case where they get disconnected, pending connection destroyed. Next, we should see player client login, we use this to pull the steamid from the clients map, followed shortly by player controller connected, which sets up the player controller. Finally, player connected pulls the current steamid and player controller, plus player suffix, sets these up in eventStore.players, emits the finished event, and does some cleanup. Other events, particularly those around player damage, are stored in eventstore.sessions. This allows us to smartly clean these up on NEW GAME events, limiting overall memory growth within the logparser. |
Managed to finish some testing and this should be good. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
We removed steamid-connected in this PR
There are however still calls to the corresponding event store that is now empty
Thank you for this change! Love the pic to make the flow more understandable! |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Tested long term on a live server. No issues reported.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Looks good to me, and I gather this has been tested long-term in production.
A few minor questions and some quick fixes to apply, but otherwise looks good to merge.
Ah, could you also rename the PR to something suitable for the changelog please?
Resolve conflict with master Change steamid-connected to client-login for consistent naming
In the process of renaming steamid-connected I had to roll forward to master branch to deal with merge conflicts But this should be good to go |
Changes have been made, new review is needed.
This is an initial port of changes from one of my branches
Fixes new EAC issues, provides a more reliable connection flow.
#257
Fixes Eventstore memory growth
#235