Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
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
[Access] Implement keepalive routine with ping-ponging to ws connection in ws controller #6757
base: master
Are you sure you want to change the base?
[Access] Implement keepalive routine with ping-ponging to ws connection in ws controller #6757
Changes from 16 commits
81ddee5
808b54b
6c5ab5d
eec15e5
fd567aa
098c10d
917bbde
438b130
86cdb35
ec4e247
eae6bbf
4e2d35c
9971188
6cd2841
c90d75f
afc8648
040a949
357dc2f
276ea7e
077c543
21259ce
1f5728d
f384b0a
66d0607
3cfe98b
File filter
Filter by extension
Conversations
Jump to
There are no files selected for viewing
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.
why less? intuitively I would have thought it would need to be larger. Can you elaborate more in this comment
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.
I guess Ulyana took it from here https://github.com/gorilla/websocket/blob/v1.5.3/examples/chat/client.go#L23.
I believe it's because ping and pong share the same timer.
Let’s consider a case where
pongWait
is smaller thanpingPeriod
, and we’ll see why this configuration is problematic.Parameters:
pongWait
= 30spingPeriod
= 40sAt t=0:
The server sends a ping message to the client.
At t=30s:
The
pongWait
expires because the server hasn't received a pong (or any message) from the client.The server assumes the connection is dead and closes it.
At t=40s:
The server sends its second ping, but the connection is already closed due to the timeout at t=30s.
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.
yea, but in that case, the server should have cleaned up the ping service when the connection was closed, so the second ping would never happen
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.
The server uses
pong
responses to confirm that the client is still alive and able to communicate. If thepong
isn't received within thePongWait
period, the server assumes the client is unresponsive and closes the connection.By setting
PingPeriod
to a smaller value thanPongWait
, the server ensures it sends a ping well before thePongWait
timeout elapses. Each newpong
message resets the server's read deadline, keeping the connection alive as long as the client is responsive.Configuration:
PongWait
= 10 secondsPingPeriod
= 9 seconds (90% ofPongWait
)Example:
At t=9, the server sends a ping
At t=10, the client responds with a pong. The server resets its read deadline to t=20.
At t=18, the server sends another ping. If the client responds with a pong at t=19, the read deadline is extended to t=29.
In case of failure:
If the client stops responding, the server will send a ping at t=9 but won't receive a pong by t=10. The server then closes the connection.
If
PingPeriod
were greater than or equal toPongWait
, the server could fail to send aping
message in time to receive apong
before the timeout expires. This would cause the server to terminate connection unnecessarily.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.
Wouldn't it be better to place it in
websockets.Config
type?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.
there is a good explanation of what this means in the code. Can you elaborate some more here. Mostly, readers will look to the definitions to understand how to set/modify the values.
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.
what do you think about using
errgroup
here instead? it handles both the goroutine lifecycle and passing errors. it has the added benefit that if an error is returned from any other goroutine, the shared context is canceled.it would look something like
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.
I'd leave this decision to be made in #6642 as the error handling/routines start might be changed
The goal of this PR is to introduce keep-alive.
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.
why wait? Is this code being introduced in another PR?
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 discussed it. Ulyana will update it in this PR
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.
is this possible? It looks like the channel is only closed in a defer
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.
This is a data race, isn't it? I'm thinking of the following situation:
c.shutdown
on this linec.shutdown
concurrently.If we need this, we have to use an atomic variable here. However, I don't understand why we need it, can you elaborate on it?
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.
when the controller is updated to allow
c.communicationChannel
to be close when shutdown is triggered, you can remove this check, and instead rely on the channel closing to signal shutdown.as it is now, if this returns here, the data providers may hang waiting to push onto the queue
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.
sync.Once
has the added functionality that it will block all other callers until the first completes. is that desired here? If not, you can just use an atomic bool with compare and swap