Client disconnects from core if downloading scrollback takes over 60 seconds (i.e. on a slow connection)
When using Quassel on a slow connection, it takes more than 60 seconds to download all the scrollback from the core. In that time, the client detects that no heartbeat has been sent from the core for 60 seconds, and closes the connection.
SUGGESTED SOLUTION: Disable heartbeat checking while scrollback is being downloaded.
#1 Updated by hagabaka about 15 years ago
I have this problem even when I run the core and client on the same machine. I have 7 networks and about 40 channels open so it takes a while for the client to download messages on start up. The client often displays only a few messages in chat monitor before it gets disconnected by core saying "didn't receive a heart beat for over 60 seconds". And I will then need to retry a few times before it finally stays connected.
Also maybe related, when I leave Quassel running over night, it usually is disconnected from core when I wake up. As well, when the CPU usage is high, Quassel sometimes gets disconnected from the core.
#2 Updated by ZRegis almost 15 years ago
Same problem for me (on protocol version 6) particularly when you are using unstable connection (aka as Wireless). You loose few packets, you loose the connection.
Sol 1: Provide a way to increase the heart beat time out.
Sol 2: beat more frequently and accept more missing beats.
Sol 3: Separate beat from data. Generally improve communication.
#6 Updated by EgS almost 15 years ago
- Assignee set to EgS
- Target version set to 0.4.0
The SignalProxy uses the heart beats only as a last resort to check if
a peer is still alive. As long as data is received the signalproxy
will be happy.
Note: the client will still disconnect from the core if no data at all is received in 60 seconds. So if your core's load skyrockets, this won't help.