~emersion/soju#11: 
Send PING to clients

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

Status
RESOLVED FIXED
Submitter
~emersion
Assigned to
No-one
Submitted
9 months ago
Updated
a day ago
Labels
downstream enhancement

~emersion 9 months ago

Enabled TCP keep-alive.

~taiite 9 months 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 8 months 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 7 months ago

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

~emersion 23 days 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 22 days 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 21 days 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 21 days ago

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

~emersion 21 days 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 21 days 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 a day 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.