When alpine is struggling to connect to a server, it gives the message
No reply in 15 seconds from server ...
and hangs. After 60 seconds, it briefly gives the option
Break connection?
However, if one misses the chance to break connection, one has to wait another minute for the option to appear again.
When this happens, I usually just "pkill alpine" in another terminal.
I was wondering if there is a neater way of interrupting alpine?
On Thu, 17 Feb 2022, N wrote:
When alpine is struggling to connect to a server, it gives the message
No reply in 15 seconds from server ...
and hangs. After 60 seconds, it briefly gives the option
Break connection?
However, if one misses the chance to break connection, one has to wait
another minute for the option to appear again.
When this happens, I usually just "pkill alpine" in another terminal.
I was wondering if there is a neater way of interrupting alpine?
dear N,
what I do is to set timeouts much lower, so that I will not have to wait for a long time. The easiest way to do this is to directly edit the
.pinerc file and reduce the tcp-*-timeouts to lower numbers. I have these
set up as follows:
# Network read warning timeout. The default is 15, the minimum is 5, and the # maximum is 1000.
tcp-read-warning-timeout=6
# Network write warning timeout. The default is 0 (unset), the minimum
# is 5 (if not 0), and the maximum is 1000.
tcp-write-warning-timeout=15
I hope this helps.
On Thu, 17 Feb 2022, N wrote:
When alpine is struggling to connect to a server, it gives the message
No reply in 15 seconds from server ...
and hangs. After 60 seconds, it briefly gives the option
Break connection?
However, if one misses the chance to break connection, one has to wait
another minute for the option to appear again.
When this happens, I usually just "pkill alpine" in another terminal.
I was wondering if there is a neater way of interrupting alpine?
dear N,
what I do is to set timeouts much lower, so that I will not have to
wait for a long time. The easiest way to do this is to directly edit the .pinerc file and reduce the tcp-*-timeouts to lower numbers. I have
these set up as follows:
# Network read warning timeout. The default is 15, the minimum is 5, and
the
# maximum is 1000.
tcp-read-warning-timeout=6
# Network write warning timeout. The default is 0 (unset), the minimum
# is 5 (if not 0), and the maximum is 1000.
tcp-write-warning-timeout=15
I hope this helps.
This has a problem. When doing a long operation (I think it is a search running on the server), I have to say yes to continue several times,
because the server is indeed busy.
On Sat, 19 Feb 2022, Carlos E.R. wrote:
This has a problem. When doing a long operation (I think it is a
search running on the server), I have to say yes to continue several
times, because the server is indeed busy.
TLDR: If you know why you have a timeout, you can ignore it or keep the connection open until the operation completes.
I agree that there are problems. The problem really stems from having
this option at all. You can either programmatically close a connection
when it does not reply automatically, or you can have the user tell you
when too much is too much. Apline does the latter, and the problem with
this is that some operations are slow (sorting, searching, etc.) and for
them you will probably timeout in some moment. It is hard for anyone to distinguish if the delay is due to a bad connection or a slow operation.
Because of that, I never answer the timeout question the first time when
I am doing a slow operation, and just let Alpine continue, or always
answer no, if I feel I need to. If the operation takes too long I will interrupt the operation, but most times I do not have to do anything. I
just know that I might get the question about breaking the connection
closed and just simply ignore it.
The problem (from my point of view) is that you can not interrupt it at
will, any second. Just have it run continuously, no questions, but allow
to interrupt any second, not having to wait for the next prompt window.
| Sysop: | Keyop |
|---|---|
| Location: | Huddersfield, West Yorkshire, UK |
| Users: | 715 |
| Nodes: | 16 (0 / 16) |
| Uptime: | 169:38:57 |
| Calls: | 12,097 |
| Calls today: | 5 |
| Files: | 15,003 |
| Messages: | 6,517,838 |