Skip to content
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

Bring back client expecting heartbeats #231

Merged
merged 3 commits into from
Jul 12, 2024
Merged

Bring back client expecting heartbeats #231

merged 3 commits into from
Jul 12, 2024

Conversation

masad-frost
Copy link
Member

Why

We removed the client being required to send heartbeat on interval due to browser timer throttling in #220. That makes sense, since we don't want the server to expect anything from the client that relies on client timers, making the timer server authoritative makes sense.

That said, this entirely removed our ability to detect bad servers or phantom disconnects on the client.

What changed

Add a client timer to expect a heartbeat from the server every options.heartbeatsUntilDead * options.heartbeatIntervalMs , if we don't see a heartbeat, we close the connection.

This is fine in the context of browser throttling timers since in the worst case of throttling we're holding on a connection for too long, and in the best case we can detect bad connections.

Versioning

  • Breaking protocol change
  • Breaking ts/js API change

Internal change.

@masad-frost masad-frost requested a review from a team as a code owner July 11, 2024 20:08
@masad-frost masad-frost requested review from bradymadden97 and removed request for a team July 11, 2024 20:08
Comment on lines 33 to 36
private activeHeartbeatHandle?: ReturnType<typeof setInterval> | undefined;
private activeHeartbeatMisses = 0;

private passiveHearbeatHandle?: ReturnType<typeof setTimeout> | undefined;
Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I'm not a fan of the same class here being used in different ways by the client and the server, ideally we'd have a ClientSessionConnected and ServerSessionConnected but that seems like a can of warms.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

big same, i asked to split this state due to the presence / absence of the heartbeat handle being significant state deviation.

@masad-frost
Copy link
Member Author

working on a test, but wanted to get some 👀

Copy link
Contributor

@lhchavez lhchavez left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

looks okay at first blush.

Comment on lines 33 to 36
private activeHeartbeatHandle?: ReturnType<typeof setInterval> | undefined;
private activeHeartbeatMisses = 0;

private passiveHearbeatHandle?: ReturnType<typeof setTimeout> | undefined;
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

big same, i asked to split this state due to the presence / absence of the heartbeat handle being significant state deviation.

Copy link
Member

@jackyzha0 jackyzha0 left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

What if we just moved the heartbeat handling outside the state machine so client/server have no difference

change the session to heartbeat always via a callback and make client/server deal w the heartbeat cb differently

@masad-frost
Copy link
Member Author

masad-frost commented Jul 11, 2024

What if we just moved the heartbeat handling outside the state machine so client/server have no difference

change the session to heartbeat always via a callback and make client/server deal w the heartbeat cb differently

I like that it's contained within the state machine so that we don't have to deal with state that only belongs to connected sessions outside of connected sessions.

Like it'd be unfortunate if we forgot the heartbeat timer while we're transparently reconnecting and then killed the connection or whatever. Things are self contained now, it's great

@jackyzha0
Copy link
Member

What if we just moved the heartbeat handling outside the state machine so client/server have no difference
change the session to heartbeat always via a callback and make client/server deal w the heartbeat cb differently

I like that it's contained within the state machine so that we don't have to deal with state that only belongs to connected sessions outside of connected sessions.

Like it'd be unfortunate if we forgot the heartbeat timer while we're transparently reconnecting and then killed the connection or whatever. Things are self contained now, it's great

oh i mean the timer would still be in the state machine just the handling of the timer events is outside of it

@bradymadden97 bradymadden97 removed their request for review July 12, 2024 01:51
private activeHeartbeatHandle?: ReturnType<typeof setInterval> | undefined;
private activeHeartbeatMisses = 0;

private passiveHearbeatHandle?: ReturnType<typeof setTimeout> | undefined;
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Suggested change
private passiveHearbeatHandle?: ReturnType<typeof setTimeout> | undefined;
private passiveHeartbeatHandle?: ReturnType<typeof setTimeout> | undefined;

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Not a fan of pirate speak? 😆

Good catch

@jackyzha0 jackyzha0 merged commit 5d079d8 into main Jul 12, 2024
4 checks passed
@jackyzha0 jackyzha0 deleted the fm-heartbeat-client branch July 12, 2024 18:12
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants