~emersion 3 years ago

Enabled TCP keep-alive.

~taiite 3 years 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 3 years 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 3 years ago

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

~emersion added enhancement 2 years ago

~emersion added downstream 2 years ago

~emersion 2 years 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 2 years 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 2 years 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 2 years ago

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

~emersion 2 years 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 2 years 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 2 years ago

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

Created #100 for delivery reports during history playback.