[348] in linux-net channel archive
Re: Does NcFTP tickle a race?
daemon@ATHENA.MIT.EDU (Tom May)
Fri May 19 15:13:42 1995
Date: Fri, 19 May 1995 11:08:15 -0700
From: ftom@netcom.com (Tom May)
To: steve@erinet.com
CC: linux-net@vger.rutgers.edu
In-reply-to: <199505191701.NAA03872@localhost.erinet.com> (steve@erinet.com)
Steven J. Madsen <steve@erinet.com> writes:
> The symptoms are simple. If I try to put a file with NcFTP, it
>sends out the first 32k (seen by the stat bar), and my modem goes to work
>sending out the packets. NcFTP then starts to time out, since the second
>32k can't be sent until the first 32k is gone. Eventually, it times out and
>aborts the transfer, and only the first 32k has been queued up or sent.
>/usr/bin/ftp works perfectly, so that's what I've been using for sending out
>files.
> Here's the interesting part. Since I'm on a 28.8 link, and it takes
>about one minute for NcFTP to give up, I can usually get between 150k and
>200k of data actually sent. The modem is constantly busy sending, but it
>appears to send the *same* 32k block over and over again. Examining the
>destination file shows that it does contain more than 32k of data, but it
>seems to be the same data. For example, sending a tar file, I only get the
>filenames for about the first 32k, after which it gets confused, even though
>the file is 150k or larger.
> Since 1.3 is probably coming quite soon, should I just abandon the
>1.2.x networking code and start working with the 1.3 code, or is this more
>likely a problem with NcFTP?
I have that problem using NcFTP with both the 1.2.8 and 1.3 networking
code (14.4k SLIP link courtesy of SLiRP). I have to use ftp for puts.
That, needless to say, sucks. Somewhere in the NcFTP doc the author,
Mike Gleason, says he hardly ever does "put" anyway so it's not
suprising that it may be broken.
I tried reducing NcFTP's 32k buffer size but it didn't help.
I don't know what the problem is but my point is 1.3 doesn't fix it.
Tom.
