[Coco] FTP problems.

[Stephen H. Fischer]

Hi,

Last night,  March 04, 2004, 2:41:10 AM (end of Session) Yes, 3 AM PST.

03-04-2004 03:17:54.585 - Remote IP address: 168.121.1.1
03-04-2004 03:17:54.855 - Local IP address: 165.247.204.27

I will try again tomorrow morning. 1 - 3 AM PST after Letterman. And I will
try to keep all the logs I know about.

Also I am going to try RTSI and perhaps some others to see if the statement
that other sites have no problem is correct. I just downloaded 1 or 2 files
from RTSI to check.

Saturday I will use my backup system to upload the B.L.CoCo logs for years
1991-1995. I have not tried uploading as I do not wish to give you bad
files. 1996 and 1997 missing. Anyone?

------------------------------------------------

KnudsenMJ-YDxpq3io04c at public.gmane.org wrote:
> In a message dated 3/4/04 6:19:47 AM Eastern Standard Time,
> SFischer1-RkSGfkmD84MysxA8WJXlww at public.gmane.org writes:
>
>> Large file transfers start OK. Soon the transfer stops and just a few
>>  bits dribble in slowly and if I wait for the end the resulting file is
>> no good.
>
> A lot of file transfers work that way -- start off fast, then slow way
> down. But in my case they are usually good, finally.  I haven't tried
> Dennis' site yet.
>
> I suspect some servers are optimized to give out, say, 50K very fast in a
> burst, hoping that will finish the file and the transfer will go away.
> But if the file is bigger, the remainder gets a lower priority.  This
> would optimize handling a lot of small-file requests, which is what
> servers usually do (an HTML page or small graphic, e.g.).
>
>   I run AOL/IE5 and Win98.  --Mike K.

Remember, I said the resulting files are consistently bad, ZIP or other
errors.

Dennis Bathory-Kitsz wrote:
> At 03:16 AM 3/4/04 -0800, Stephen H. Fischer wrote:
>> Large file transfers start OK. Soon the transfer stops and just a few
>> bits dribble in slowly and if I wait for the end the resulting file is
>> no good.
>
> In WS_FTP, try setting PASV mode. (Options -> Advanced -> Site -> Use
> passive transfer mode).

Will try this.

>> The problem occurs with WS_FTP and Internet Explorer both on Win XP
>> which is current with all patches.
>
> Thought it sounds like an old stability problem I used to have with
> earlier versions of the Windows stack. Of WinXP I have no idea, though.
>
>> Perchance does your system generate any logs that might help me?
>
> What's your IP address? What day? I looked through yesterday, and there
> were several incomplete transfers, but these were dropped on the client
> end (generating a 200 "OK" code).

I manually terminate the transfer when testing as soon as it appears the
problem is still there.

>> You have too many desirable files. I suggest we look for a place for
>> some of them with more bandwidth. Perhaps RTSI.
>
> RTSI has free bandwidth over 2GB per day?

That is a good question. I have not seen any complaints from the owner about
excessive downloads except when the server was taken over when he allowed
downloading from the incoming dir.

> I can't imagine anyone was going to use 750GB in
> documentation and programs all at once. :)
>
> Dennis

Well, someone who is doing database work might. I am looking for a method of
getting the dir.'s files list for RTSI and others. I do not need the files
themselves.

I do not think I can do much damage with my 56K connection. Earthlink has a
limit on Binary Newsgroups, but says that 56K people need not worry.

Still, you should turn on any limiting that you can. The number of high
speed connections is growing minute by minute.

I have aborted the WS_FTP /sync/ program several times when I was trying to
check RTSI for new files when it starting redownloading all files. Never got
what I wanted, just a listing of the files information.

A person with a fast connection would have downloaded all the files just
trying to stop it. Dangerous program!

Another one is HTTrack. That program will most times suck all the files from
a site, the defaults are set to not download the entire Internet, but an
error in settings (many ways) will start the full Internet download. It has
a large number of concurrent connections and is hard to control or stop.
Another Dangerous program. There are many others.

The real problem is that HTTrack is the best site image collector in that
more of the site is actually useful when done compared with other methods.

Stephen H. Fischer <sfischer1 at mindspring.com>

-------------- next part --------------
A non-text attachment was scrubbed...
Name: original.ini
Type: application/octet-stream
Size: 1256 bytes
Desc: not available
URL: <http://five.pairlist.net/pipermail/coco/attachments/20040304/b4c3d0f9/attachment-0001.obj>