Send PING to downstream connections at regular intervals. Disconnect them if they don't reply fast enough.
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.
We could also use
PINGfor "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.
Note to self: remember to set a
net.Connread deadline after sending a PING. Unset it after receiving the right PONG.
WIP patch available in branch
- 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
We shouldn't send a PING if a message is sent to a detached channel
Actually this is already properly handled inside
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.)
Send a single PING after the history is sent (if not empty) for clients that do not support CHATHISTORY?
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).
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?
This issue is fixed in e797d90c59a6 ("Implement delivery receipts via PING messages").
Created #100 for delivery reports during history playback.