emacs-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [RFC] automatically retrying network connections


From: Lars Ingebrigtsen
Subject: Re: [RFC] automatically retrying network connections
Date: Sun, 22 Jul 2018 12:59:30 +0200
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/27.0.50 (gnu/linux)

Robert Pluim <address@hidden> writes:

> Thereʼs this little-known news server called news.gmane.org that has a
> 10 second timeout :-) Reconnecting immediately works, so itʼs not a
> big deal.

Never heard about it.  :-)

> So you'd put this in nsm-verify-connection, without a user option? I
> donʼt think nsm currently has access to all the connection setup
> parameters, which is why I put the logic in open-network-stream.
> Proof-of-concept patch attached (it should really do more checking of
> what nsm returned).

I was thinking that the `nsm-verify-connection' call sites would
reconnect that function said "go ahead" and the process was dead.  Which
is basically if it returns non-nil, I guess, so the return value of that
function doesn't have to change.

:retry-on-fail is too general -- it's not really useful to reestablish
the connection if the server closes the connection for other reasons
than an NSM-related timeout.

>> We could also reverse the logic a bit and have the NSM always shut down
>> the connection before prompting.  This will make network connections
>> (that prompt an NSM warning) be somewhat slower, but it shouldn't be a
>> big deal.
>
> That seems wasteful. In most cases the connection will complete OK, so
> why add an extra connection setup for all cases?

An NSM warning isn't the common case, and reestablishing the connection
would be a minuscule extra delay.  It would just be more...  consistent?
But little real-world impact.

>> In any case, when reconnecting we have to consider whether this would
>> trigger extra auth-source prompts, which would be annoying, but I have a
>> feeling like these are mostly done later in the connection process
>> usually, so it shouldn't be an issue.
>
> If youʼre thinking of authentication for SMTP sessions and the like,
> they'd all arrive after completion of the TLS setup.

I think so, too, but we should audit the call sites and ensure that
nobody does stuff like

(open-network-stream ... :starttls-function () (auth-source-search ...))

Seems unlikely, though.

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no



reply via email to

[Prev in Thread] Current Thread [Next in Thread]