On 2/23/2021 3:47 PM, ad5rb wrote:
Recently, while trying to get standardized on the latest 0.3.9
version, I have ratflector connections timing out at around 5
minutes.
That should not be a problem as if everything is working correctly it should just reconnect.
On my windows systems, though the client does not reconnect, instead it misses the disconnect signal for some unknown reason and goes CPU bound.
The disconnect that I see, which is similar to what you report is not a timer in the D-rats. It is my ISP that disconnects any session that is idle for 5 minutes.
The simple cure is to run a QST announcement every 4 minutes. Only
one station needs to be running this and it seems to keep all
stations connected. This is running on Windows 10 machines, but I
also have an Ubuntu Linux laptop that does the same 5 minute time
out. Running a 6 minute QST announce does not work.
Currently that is the only work around that I have.
While the cure is simple, it does result it lots of clutter on the
Main chat page. Again, not a problem if a separate Channel is used
for the primary conversation, but then everyone needs to know about
the Channel.
Is it worth trying to modify the D-Rats client so the TCP port time
out is set to something like 30 minutes or an hour? Running a QST
once an hour makes a nice clock so you realize how much time you are
spending, but every 4 minutes is a little excessive in my opinion.
I am not aware of any such control.
What is needed in my case is a TCP/IP keep-alive to prevent the connection from timing out.
And also to find out why the disconnection is not being signaled on Windows.
That is something that I am going to look at after getting d-rats to work on python3.
-John
wb8tyw@...
