fix(dgw,jetsocat): implement WebSocket keep-alive logic

[CBenoit]

Our WebSockets are already responding Pong messages to Ping messages, but they were never sending Ping messages.

[pacmancoder]

Doesn't #[derive(Debug)] produce the same output?

[CBenoit]

It's not derivable because T does not necessarily implement Debug. Unless they improved that recently?

[pacmancoder]

Huh, it compiled successfully on playground at least https://play.rust-lang.org/?version=stable&mode=debug&edition=2021&gist=238783f816438c16430a790e0df7ddb4

[CBenoit]

Oh! Good to know!

However, I still prefer the current implementation which gives:

Mutex { data: 42 }

Instead of

PinnableMutex(Mutex { data: 42 })

The PinnableMutex part is not relevant, the same way it’s not relevant for Pin:
https://doc.rust-lang.org/nightly/src/core/pin.rs.html#1701-1705

Both Pin and PinnableMutex are irrelevant at runtime, it’s just type gymnastic to ensure code correctness at compile-time.

As a result, for this code:

use core::fmt;

use parking_lot; // 0.12.3

pub struct PinnableMutex<T: ?Sized>(parking_lot::Mutex<T>);

impl<T: ?Sized> fmt::Debug for PinnableMutex<T>
where
    T: fmt::Debug,
{
    fn fmt(&self, f: &mut fmt::Formatter<'_>) -> fmt::Result {
        fmt::Debug::fmt(&self.0, f)
    }
}

fn main() {
    let pinned_mutex = core::pin::pin!(PinnableMutex(parking_lot::Mutex::new(42)));
    println!("{pinned_mutex:?}");
}

We get this output:

Mutex { data: 42 }

The only runtime-relevant information.

[pacmancoder]

Question: Blocking on sync mutex in async future feels wrong, does using async mutex reduce performance drastically?

[CBenoit]

It does reduce performance considerably to use async Mutex, and it's not wrong to use a sync one unless you hold the mutex across async points. Here, it's not the case, the poll functions should return ASAP, either returning the result, or registering the task for later wake up using the Context/Waker.
I recommend this read: https://ryhl.io/blog/async-what-is-blocking/
And this one: https://tokio.rs/tokio/tutorial/shared-state

I used parking_lot mutex because it is the most lightweight and performant option for low-contention scenarios like this one. The performance hit is negligible.

Side merit: simpler code, no nested polling. (Of course, it's okay only thanks to the points above.)

[pacmancoder]

Thank you! Interesting, I'll take a read

[CBenoit]

I pushed a commit to improve the documentation directly in the code: 9b42424

[pacmancoder]

Looks good! Approved in advance, however I am a bit confused about parking_lot sync Mutex usage in futures, could you elaborate on this approach?

[CBenoit]

Looks good! Approved in advance, however I am a bit confused about parking_lot sync Mutex usage in futures, could you elaborate on this approach?

Of course! I should include the rationale in the documentation: #1202 (comment)

[CBenoit]

Also implemented the keepalive logic for Gateway -> Target server in /jet/fwd/tls route: 17f0a95