Subject: Re: Hanging ftpd processes

From: Bob Woodward <[email-masked]>
Date: Fri, 07 Mar 1997 14:59:14 -0800

At 11:10 AM 3/7/97 CST, you wrote:
>[Re ftpd hanging...]
>> >So probably setting the keepalive option when opening a socket
>> >can be an insteresting workd around.
>> >
>> >Other ideas ?
>> 
>>    How about instead of setting an alarm(0) (clearing the alarm) when
exiting
>> the command loop to process a command, set a larger alarm time like 24
hours?
>> This alarm would limit the maximum amount of time that any one file
transfer
>> can take, but would still allow the ftp session to last more than a day in
>> total.
>
>I'd be _most_ unhappy about this, unless it is an option which can be set via
>the ftpaccess file, and the duration could be specified or set to "no time
>out" (set the duration to 0 ?).
>
>I have had genuine transfers from my server which have taken longer than
>24 hours to complete.  If a user waits a long time for a large file to
>transfer, only for it to fail before completion due to a 24 hour timeout,
>they aren't going to be best pleased...
>
If this is a 'normal' situation for that site, though, they would take
steps to make sure downloads from them would be allowed sufficent time to
complete.  Our site, anything over an hour or two is almost guarenteed to
be 'lost.'

----------
Bob Woodward, Seattle FilmWorks     ([email-masked])
Data Processing Department	(206) 281-1390 ext. 475

Visit our Web Site to learn about getting your pictures via downloads on
the Internet!
Point your browser to "http://www.filmworks.com".

---

From: Bob Luckin <[email-masked]>
Date: Fri, 7 Mar 97 17:28:21 CST

>complete.  Our site, anything over an hour or two is almost guarenteed to

Exactly.  Which is why I wouldn't want any specific value hard-coded into
the source.  If the timeout value could be switched on/off and set via
the ftpaccess file, then each site could "take steps" appropriate to them,
by setting a suitable value.  This is much better than having to recompile
every time you want to change the value.

In our case, I'd not want it enabled at all.  Even if it takes 24+ hours to
send 400 Mbytes of data to some of our international sites via ftp, it's still
a lot faster (and much less customs hassle) than trying to mail it.  :-)

Cheers, Bob
-- 
Bob Luckin      [email-masked]      "A man, a plan, a canal, Suez !"

---

From: Alain Magloire <[email-masked]>
Date: Fri, 7 Mar 1997 22:14:41 -0500 (EST)

Bonjour Mr Bob Luckin

> >>out" (set the duration to 0 ?).

Just a reminder:
Timeout is configurable on the command line "-t"

It is also configurable by the client

site idle new_timeout
or
quote site idle new_timeout

the timeout that is implemented now is only enable when doing
command parsing. It's disable when doing transfert.
.i.e transfert can take an hour, a day, a month, ... a year..
it doesn't matter to TCP, if the two machines are not rebooted
the connection will stay, it doesn't matter if the world came
crumbling down in between.

I do understand your arguments,
the default timeout now is 15 mins and it's possible for the client
to renable it up to 2 hours.

But what kind of numbers to have when doing transfert({up,down}load) ???
2 hours, a day, a week ??

no easy answers.

-- 
au revoir, alain