Send PING to clients

Send PING to downstream connections at regular intervals. Disconnect them if they don't reply fast enough.

Assigned to
1 year, 1 month ago
4 months ago
downstream enhancement

~emersion 1 year, 1 month ago

Enabled TCP keep-alive.

~taiite 1 year, 1 month ago

TCP keep-alive is for the transport layer. If/when jounce aims to be more robust, it should send PINGs to make sure that downstream clients have a working application layer.

~emersion 1 year, 1 month ago

We could also use PING for "read receipts" to avoid loosing messages: after sending a burst of messages, send PING <token>. When we receive PONG <token> we know the client has received and processed the messages.

~emersion 1 year, 11 days ago

Note to self: remember to set a net.Conn read deadline after sending a PING. Unset it after receiving the right PONG.

~emersion 5 months ago*

WIP patch available in branch ping-pong. TODO:

  • No need to keep track of history if the client supports CHATHISTORY
  • We shouldn't send a PING if a message is sent to a detached channel

~emersion 5 months ago

We shouldn't send a PING if a message is sent to a detached channel

Actually this is already properly handled inside upstreamConn.produce.

~emersion 5 months ago

Another question: what should we do when replaying history? Just dump the whole thing and expect the client to receive it all? (That's the current assumption.)

~delthas 5 months ago

Send a single PING after the history is sent (if not empty) for clients that do not support CHATHISTORY?

~emersion 5 months ago

That means that we'll re-play the whole history if the client doesn't reply to the final PING. This may be an issue if the network is unreliable and we need to send a lot of history (soju sends history, TCP connection breaks, client re-connects, soju sends history again, etc).

~delthas 5 months ago

Exactly. In cases where my connection is unstable and the TCP connection repeteadly breaks, I'd like to soju to ensure that I did receive everything before dropping it. In other bouncers that simply fire & forget the history, these messages are lost.

But it's true that for example when a client that has not connected in 12 months reconnects, it'll receive so many messages it might actually freeze, the user might kill it, and then he'll be stuck in this situation. I suggest sending perhaps 1 PING every 1000 messages + 1 at the end. Thoughts?

~emersion REPORTED FIXED 4 months ago

This issue is fixed in e797d90c59a6 ("Implement delivery receipts via PING messages").

Created #100 for delivery reports during history playback.

Register here or Log in to comment, or comment via email.