cURL / Mailing Lists / curl-users / Single Mail

curl-users

Re: Using Curl to FTP

From: <pirateroberts_at_comcast.net>
Date: Sun, 01 Jul 2007 05:29:11 +0000

UNSUBSCRIBE

-------------- Original message --------------
From: Alessandro Vesely <vesely_at_tana.it>

> Park Darkness wrote:
> > Hi Daniel,
> >
> > Thanks for your replies.
> >
> > /> I think the ftp connection will not be closed after each upload. /
> >
> > You think wrong. If you use curl to upload a single file, both the
> > connections
> > are always closed.
> >
> > -> I saw the following point under the internal design under persistent
> > connection at http://curl.haxx.se/docs/internals.html
> > "When the transfer operation is complete, we try to leave the connection
> > open. Particular options may tell us not to, and protocols may signal
> > closure on connections and then we don't keep it open of course."
> > I am not sure if this is the same for a normal FTP uploading and if
> > there is option to be set how should i go about it?
> > I think i read it somewhere that there is a config file that you can
> > create to load it while using curl.
>
> That's the inner working of curl. Use the -v/--verbose option and you
> will see that the connection is being kept open until there are more
> jobs to be done with it. It is closed just before exiting.
>
>
> > /> I am trying to upload multiple files thus the number of connections
> > to the /
> > /> ftp server seems to keep increasing. /
> >
> > They "seem" so? How do you determine that and why do you think curl is to
> > blame?
> >
> > -> I am not blaming curl that is for sure. I am just trying to find out
> > more.
> >
> > For example, what i did was to test for example 1000 files uploading to
> > the ftp server over the span of 5 minutes.
> > At the 5th minutes the connection to the ftp is close to 1000.
> >
> > That is why i am asking if the connection is being closed once the
> > transfer is over.
>
> Your TCP/IP stack may choose different local port numbers for each new
> connection, in order to diminish the likelihood that any roving packet
> can be misinterpreted as belonging to the wrong connection. Old
> connections may remain in a wait status for a while for that reason.
>
> Try and run netstat on both machines, if possible. At least, run it on
> the client to ascertain the difference between "seem" and "are"...
>
Received on 2007-07-01