Break connection?

[N]

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?

[Eduardo Chappa]

Post by N
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.

[N]

Post by Eduardo Chappa

Post by N
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
# 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.

Thanks for this (and, more generally, thanks very much for maintaining
Alpine)!

[Carlos E.R.]

Post by Eduardo Chappa

Post by N
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
# 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.

[Eduardo Chappa]

Post by Carlos E.R.
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.

[Carlos E.R.]

Post by Eduardo Chappa

Post by Carlos E.R.
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.

[Eduardo Chappa]

Post by Carlos E.R.
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.

I agree. That's why I recommend to keep the timeouts low and use your best
judgement to try to figure out if a timeout is because of a broken
connection or a slow operation in the server.