all messages for Emacs-related lists mirrored at yhetil.org
 help / color / mirror / code / Atom feed
From: Lars Ingebrigtsen <larsi@gnus.org>
To: emacs-devel@gnu.org
Subject: Re: [RFC] automatically retrying network connections
Date: Sun, 22 Jul 2018 12:59:30 +0200	[thread overview]
Message-ID: <m37elno7sd.fsf@gnus.org> (raw)
In-Reply-To: <87fu0bft72.fsf@gmail.com> (Robert Pluim's message of "Sun, 22 Jul 2018 12:41:53 +0200")

Robert Pluim <rpluim@gmail.com> 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	other threads:[~2018-07-22 10:59 UTC|newest]

Thread overview: 23+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-07-20 20:06 [RFC] automatically retrying network connections Robert Pluim
2018-07-21 15:21 ` Jimmy Yuen Ho Wong
2018-07-22 10:28   ` Lars Ingebrigtsen
2018-07-22 14:28     ` Jimmy Yuen Ho Wong
2018-07-22 16:44       ` Michael Albinus
2018-07-22 23:24         ` Jimmy Yuen Ho Wong
2018-07-22 11:18   ` Robert Pluim
2018-07-22 11:43     ` Lars Ingebrigtsen
2018-07-22 23:29       ` Jimmy Yuen Ho Wong
2018-07-23  7:41         ` Andreas Schwab
2018-07-22 10:24 ` Lars Ingebrigtsen
2018-07-22 10:41   ` Robert Pluim
2018-07-22 10:59     ` Lars Ingebrigtsen [this message]
2018-07-22 14:08       ` Robert Pluim
2018-07-22 14:29         ` Lars Ingebrigtsen
2018-07-22 13:32   ` Andy Moreton
2018-07-22 13:35     ` Lars Ingebrigtsen
2018-07-22 23:27     ` Jimmy Yuen Ho Wong
2018-07-23  8:23       ` Robert Pluim
2018-07-23 20:57         ` Jimmy Yuen Ho Wong
2018-07-22 13:37   ` Noam Postavsky
2018-07-22 13:41     ` Lars Ingebrigtsen
2018-07-22 23:26       ` Jimmy Yuen Ho Wong

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=m37elno7sd.fsf@gnus.org \
    --to=larsi@gnus.org \
    --cc=emacs-devel@gnu.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
Code repositories for project(s) associated with this external index

	https://git.savannah.gnu.org/cgit/emacs.git
	https://git.savannah.gnu.org/cgit/emacs/org-mode.git

This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.