-
Notifications
You must be signed in to change notification settings - Fork 173
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
Implement ping-pong
for WebSocket clients
#772
Conversation
Signed-off-by: Alexandru Vasile <[email protected]>
Signed-off-by: Alexandru Vasile <[email protected]>
Signed-off-by: Alexandru Vasile <[email protected]>
Signed-off-by: Alexandru Vasile <[email protected]>
Signed-off-by: Alexandru Vasile <[email protected]>
Signed-off-by: Alexandru Vasile <[email protected]>
hehe, the idea behind the issue was to implement server-side pings based on what Jaco told us about JS-side of things here however, I think this is useful for the client as well. |
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 overall 👍
It would be better to make the extra ping/pongs optional and disable it by default.
I think there a might be a use case where one wants avoid this extra overhead to send these extra messages (not exactly sure but currently it's not possible to turn it off except a very long ping interval)
Signed-off-by: Alexandru Vasile <[email protected]>
Signed-off-by: Alexandru Vasile <[email protected]>
Signed-off-by: Alexandru Vasile <[email protected]>
Signed-off-by: Alexandru Vasile <[email protected]>
Signed-off-by: Alexandru Vasile <[email protected]>
Signed-off-by: Alexandru Vasile <[email protected]>
Signed-off-by: Alexandru Vasile <[email protected]>
Signed-off-by: Alexandru Vasile <[email protected]>
Signed-off-by: Alexandru Vasile <[email protected]>
Signed-off-by: Alexandru Vasile <[email protected]>
Signed-off-by: Alexandru Vasile <[email protected]>
) -> Result<(), Error> { | ||
|
||
// Handle raw messages of form `ReceivedMessage::Bytes` (Vec<u8>) or ReceivedMessage::Data` (String). | ||
async fn handle_recv_message<S: TransportSenderT>( |
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.
So I am under the impression the reason this is nested is this fn
is only used locally within the scope of handle_backend_messages
? I quite like it actually as it distinquishes the difference between handling frontend messages and backend message. 👍 Nice cleanup from it earlier being inside of the fn background_task
. It's way easier to read/digest.
core/src/client/async_client/mod.rs
Outdated
|
||
Some(FrontToBack::Batch(batch)) => { | ||
tracing::trace!("[backend]: client prepares to send batch request: {:?}", batch.raw); | ||
// NOTE(niklasad1): annoying allocation. |
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.
@niklasad1 DQ: Just wondering, I've seen this before and have wanted to ask, what specifically about the clone allocation is annoying here?
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 can remove that note but it's just the those are batch ids
are already owned in this scope and so should be possible to borrow that in theory
but we use the HashSet entry which takes ownership of that +
RequestManager` doesn't allow borrows for simplicity.
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.
👍 Great Job!
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.
blocking this because of the trace logging thingy
Co-authored-by: Tarik Gul <[email protected]>
Co-authored-by: Tarik Gul <[email protected]>
Co-authored-by: Tarik Gul <[email protected]>
Co-authored-by: Tarik Gul <[email protected]>
Co-authored-by: Tarik Gul <[email protected]>
Co-authored-by: Niklas Adolfsson <[email protected]>
Co-authored-by: Niklas Adolfsson <[email protected]>
@@ -195,6 +197,20 @@ impl TransportSenderT for Sender { | |||
Ok(()) | |||
} | |||
|
|||
/// Sends out a ping request. Returns a `Future` that finishes when the request has been | |||
/// successfully sent. |
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.
Since we've been talking about cancel safety a bit, and not really relaetd to this PR, but do you reckon it is worth adding an issue to add docs to functions to note when they aren't cancel safe @niklasad1?
(or maybe almost no methods are cancel safe, and we state that up front and then note which ones are, perhaps)
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.
sounds like a good idea.
Signed-off-by: Alexandru Vasile <[email protected]>
Signed-off-by: Alexandru Vasile <[email protected]>
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.
nice work, forgot about this one
This PR exposes the ping-pong interface of the WebSocket clients.
A new
ping_interval
configuration is exposed for async-clients.The ping interval represents the amount of time that should be elapsed between
an activity event (frontend event, backend event /
pong
frame received)and submitting a ping frame to the RPC server.
From the RPC: https://www.rfc-editor.org/rfc/rfc6455#section-5.5.2
It is possible that the
Pong
reply is not submitted in the expected time(ie if the server received a
state_getKeys
request that is taking minutes to finish).Therefore the
ping_interval
is set to 5 minutes to capture those cases.Closes #738.