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.

--
Eduardo
https://tinyurl.com/yc377wlh (web)
http://repo.or.cz/alpine.git (Git)

Eduardo Chappa <chappa@washington.edu> wrote:
> 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.
>

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

On 2022-02-17 16:07, Eduardo Chappa wrote:
> 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.

--
Cheers, Carlos.

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.

--
Eduardo
https://tinyurl.com/yc377wlh (web)
http://repo.or.cz/alpine.git (Git)

On 2022-02-19 23:15, Eduardo Chappa wrote:
> 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.

--
Cheers, Carlos.

On Thu, 24 Feb 2022, Carlos E.R. wrote:

> 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.

--
Eduardo
https://tinyurl.com/yc377wlh (web)
http://repo.or.cz/alpine.git (Git)