curl / Mailing Lists / curl-library / Single Mail


Re: asynchron events / the easy interface

From: Daniel Stenberg <>
Date: Thu, 12 Apr 2018 14:50:48 +0200 (CEST)

On Thu, 12 Apr 2018, Alexander Eisenhuth wrote:

> 1) Getting informed, when the FTP server closes the connection in a async
> way (without a FTP request) - as it would do after a while when sending no
> request

This is not really doable with libcurl. libcurl is totally transfer-oriented
and it only uses and monitors sockets when there's at least one transfer in
progress and libcurl functions are invoked.

When you don't perform any transfer, the sockets that the curl handles own are
just dormant, waiting to get used again.

> 2) Using keep alive messages to prevent from disconnecting

When you talk about "keep alive" in a FTP sense, you probably refer to sending
NOOP commands or something that is actually in the FTP layer, and not in the
TCP layer, right?

Keep alive in the FTP layer has the same problem as above: when you don't
drive any transfer with libcurl there's nothing using the sockets so they
can't do anything.

TCP level keep alive is however a kernel/TCP stack feature so that sort of
keep alive can be used.

> as I understand libcurl with the easy interface has no own thread.

That goes for all its interfaces. libcurl does not start any threads(*) and
once it returns to your application, there's nothing running in the

> So I'm a bit confused how keepidle works.

TCP Keep-live is an option you set on a TCP socket and the kernel then sends
pings over the TCP connection with an interval. That's about it.

The only really functional way I can think of to do this with libcurl, is to
fire off a new transfer every N seconds. It could be a directory listing or
fetch a non-existing file or similar.

(*) = libcurl creates and uses threads for name resolves, but only for that
and they will be killed when libcurl returns and they will never be left
around and they will not handle any transfers anyway.

Received on 2018-04-12