all messages for Emacs-related lists mirrored at yhetil.org
 help / color / mirror / code / Atom feed
* network process timeouts
@ 2016-09-22 12:22 Ted Zlatanov
  2016-09-22 12:54 ` Lars Ingebrigtsen
  0 siblings, 1 reply; 5+ messages in thread
From: Ted Zlatanov @ 2016-09-22 12:22 UTC (permalink / raw)
  To: emacs-devel

This came up as a Gnus question. I don't think Emacs today supports
connection timeouts.

Once the network connection is attempted, the control passes down to the
networking layer, which could be GnuTLS. So the timeout parameter could
be set with gnutls_handshake_set_timeout() (for which we'll need to
modify gnutls.c) or with set_socket_option(SO_RCVTIMEO/SO_SNDTIMEO) in
process.c. At the Emacs Lisp level, it would be a new parameter for
`make-network-process'.

The good news is that all packages, not just Gnus, would benefit from
that. So I think it's a good platform improvement.

If I've missed existing functionality to do network timeouts, please let
me know.

Thanks
Ted




^ permalink raw reply	[flat|nested] 5+ messages in thread

* Re: network process timeouts
  2016-09-22 12:22 network process timeouts Ted Zlatanov
@ 2016-09-22 12:54 ` Lars Ingebrigtsen
  2016-09-22 19:24   ` Ted Zlatanov
  0 siblings, 1 reply; 5+ messages in thread
From: Lars Ingebrigtsen @ 2016-09-22 12:54 UTC (permalink / raw)
  To: emacs-devel

Ted Zlatanov <tzz@lifelogs.com> writes:

> If I've missed existing functionality to do network timeouts, please let
> me know.

Timeout parameters would be nice, but you end up having to do some kind
of "global" timeout anyway, so in many cases it's surprisingly
non-useful.  :-)

For instance, I'm writing a little module now that connects to my
wifi-enabled camera, and if it's up, downloads any new images that exist
there, and inserts them into the current buffer.

The number of things that may time out is rather large.  The initial
connection (if the camera isn't on), fetching the table of contents,
and fetching the actual image.  What you end up having to do, since this
should all happen asynchronously anyway, is to start a non-blocking
connect, and then see what happens: Having the timeout as a connection
parameter doesn't really help here (since things may time out after
connection, if, for instance, the camera switches itself off after the
handshake has been completed).

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



^ permalink raw reply	[flat|nested] 5+ messages in thread

* Re: network process timeouts
  2016-09-22 12:54 ` Lars Ingebrigtsen
@ 2016-09-22 19:24   ` Ted Zlatanov
  2016-09-22 21:51     ` Lars Ingebrigtsen
  0 siblings, 1 reply; 5+ messages in thread
From: Ted Zlatanov @ 2016-09-22 19:24 UTC (permalink / raw)
  To: emacs-devel

On Thu, 22 Sep 2016 14:54:22 +0200 Lars Ingebrigtsen <larsi@gnus.org> wrote: 

LI> Ted Zlatanov <tzz@lifelogs.com> writes:
>> If I've missed existing functionality to do network timeouts, please let
>> me know.

LI> Timeout parameters would be nice, but you end up having to do some kind
LI> of "global" timeout anyway, so in many cases it's surprisingly
LI> non-useful.  :-)

OK... so I shouldn't bother? Or I'm approaching it wrong? I thought
having a timeout in `make-network-process' was the right place for a
global timeout per process, and then the underlying implementation can
choose what to do with that parameter.

Ted




^ permalink raw reply	[flat|nested] 5+ messages in thread

* Re: network process timeouts
  2016-09-22 19:24   ` Ted Zlatanov
@ 2016-09-22 21:51     ` Lars Ingebrigtsen
  2016-09-23 13:03       ` Ted Zlatanov
  0 siblings, 1 reply; 5+ messages in thread
From: Lars Ingebrigtsen @ 2016-09-22 21:51 UTC (permalink / raw)
  To: emacs-devel

Ted Zlatanov <tzz@lifelogs.com> writes:

> OK... so I shouldn't bother? Or I'm approaching it wrong? I thought
> having a timeout in `make-network-process' was the right place for a
> global timeout per process, and then the underlying implementation can
> choose what to do with that parameter.

What would the timeout be for?  DNS resolution, socket connection, TLS
negotiation or protocol negotiation?  I think having a parameter for a
timeout for the first three would perhaps be nice if you're programming
synchronous network connection stuff (for instance if you're writing
something to probe hosts to see whether they're listening to a port),
but it's still not quite enough to be generally useful, I think?

If you look at, for instance, `url-retrieve-synchronously', it does an
asynchronous connection and then loops waiting for it to finish whatever
it's doing.  Adding a timeout to that function would just involve, well,
adding a timeout to that function, and it would not pass that timeout on
to the lower levels.

So in that use case it's not useful, but perhaps you see other use cases
where this is useful?

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



^ permalink raw reply	[flat|nested] 5+ messages in thread

* Re: network process timeouts
  2016-09-22 21:51     ` Lars Ingebrigtsen
@ 2016-09-23 13:03       ` Ted Zlatanov
  0 siblings, 0 replies; 5+ messages in thread
From: Ted Zlatanov @ 2016-09-23 13:03 UTC (permalink / raw)
  To: emacs-devel

On Thu, 22 Sep 2016 23:51:21 +0200 Lars Ingebrigtsen <larsi@gnus.org> wrote: 

LI> Ted Zlatanov <tzz@lifelogs.com> writes:
>> OK... so I shouldn't bother? Or I'm approaching it wrong? I thought
>> having a timeout in `make-network-process' was the right place for a
>> global timeout per process, and then the underlying implementation can
>> choose what to do with that parameter.

LI> What would the timeout be for?  DNS resolution, socket connection, TLS
LI> negotiation or protocol negotiation?  I think having a parameter for a
LI> timeout for the first three would perhaps be nice if you're programming
LI> synchronous network connection stuff (for instance if you're writing
LI> something to probe hosts to see whether they're listening to a port),
LI> but it's still not quite enough to be generally useful, I think?

If it helps users connecting to network services, I think it's a good
thing, even if it's not everywhere. In this case, I think we can add
setsockopt() and GnuTLS calls to implement some timeouts.

LI> If you look at, for instance, `url-retrieve-synchronously', it does an
LI> asynchronous connection and then loops waiting for it to finish whatever
LI> it's doing.  Adding a timeout to that function would just involve, well,
LI> adding a timeout to that function, and it would not pass that timeout on
LI> to the lower levels.

LI> So in that use case it's not useful, but perhaps you see other use cases
LI> where this is useful?

Yes. Gnus to IMAP/NNTP for instance. Plus we should look at making the
HTTP protocol handlers better with respect to timeouts, I think, but
these are gradual ELisp improvements. The C improvements are the foundation.

Ted




^ permalink raw reply	[flat|nested] 5+ messages in thread

end of thread, other threads:[~2016-09-23 13:03 UTC | newest]

Thread overview: 5+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2016-09-22 12:22 network process timeouts Ted Zlatanov
2016-09-22 12:54 ` Lars Ingebrigtsen
2016-09-22 19:24   ` Ted Zlatanov
2016-09-22 21:51     ` Lars Ingebrigtsen
2016-09-23 13:03       ` Ted Zlatanov

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.