Go Back   FlashFXP Forums > > >

Bug Reports Report bugs here.

 
 
Thread Tools Display Modes
Old 08-05-2004, 08:05 AM   #1
OngL
Member
FlashFXP Beta Tester
 
Join Date: Aug 2004
Posts: 51
Default Possible bug - Disconnection after file transfer

Hello,

I've been getting this forever from 1.x, 2.x and now 3.0.1015. On certain FTPs (about 50% of FTPs that I use), FFXP will not be able to transfer the next file in queue after completing a file. It'll time out and then reconnect with next line in queue.

Example:
[10:26:34] [R] RETR filename
[19:26:34] [R] 150 Opening BINARY mode data connection for filename (150000 Bytes).
[10:54:51] [R] Connection lost: servername
[10:54:51] Transferred: filename 1.41 MB in 28 minutes 7 seconds (3.7 KB/s)
[10:54:52] [R] Attempting to Reconnect.
[10:54:53] [R] Connecting to servername -> IP=xxxx (attempt # 1)
[19:54:53] [R] Connected to servername

With this issue, it'll take significantly longer to finish all queue because each file will need to timeout and end session plus another 2 minutes before the next reconnectiong attempt. Multiple these by 10, 20 or 30 files, it'll take hours just for these waiting time.

Btw this is just normal ftp, not FXP.

Any ideas ?
OngL is offline  
Old 08-05-2004, 08:39 AM   #2
Outlaw
Junior Member
 
Join Date: Aug 2004
Posts: 5
Default disconnects and reconnects during a multi files transfer

I am having this problem with this version 3.0 1015 all the other versions of flashfxp have never given me this problem and it is very frustrating and time consuming trying to send multiple files with the idle time and reconnect.

tried to set the noop but that didn't help with keeping the connect flowing without the disconnect and reconnect between files.

I have seen several posts pertaining to this problem throughout the forum and wondering if there is a fix?

* FlashFXP v[3 ].[0 ], build [1015 ], [X ]registered, [ ]unregistered, [ ]pirated
* OS [ ] WinXP, [X ] Win2K, [ ] Win98, [ ] WinME, [ ] Other
* Running behind NAT/router [ ] Yes & Model [ ], [X ] No, [ ] Not sure
* Running firewall [ ] Yes, Name [ ], Ver. [ ], or [X ] No
* Running Antivirus [X ] Yes, Name [nortons 2004 av ] or [ ] No
* Network [ ] xDSL, [X ] CABLE, [ ] Dail-Up, [ ] Other
Outlaw is offline  
Old 08-05-2004, 08:56 AM   #3
Harm
Too much time...
Ultimate Scripter
 
Join Date: Jul 2003
Posts: 1,430
Default

Are you sending NOOP during transfers too ?
Preferences > Connection > Send noops during transfer.
Harm is offline  
Old 08-05-2004, 09:06 AM   #4
Outlaw
Junior Member
 
Join Date: Aug 2004
Posts: 5
Default

yes tried both ways with and without noop and tried different nops sends ie 120 sec down to every 10 sec.

also when i did set the noop i did come back to find myself still connect the the site but inbetween it was still disconnecting and reconnecting during multiple file transfers. So the noop works and is actually keeping me connect after the last files sent but not during multi files sent .
Outlaw is offline  
Old 08-05-2004, 10:24 AM   #5
OngL
Member
FlashFXP Beta Tester
 
Join Date: Aug 2004
Posts: 51
Default

NOOP helps when there is no activities, we are referring to after file download completed, FFXP should have detected it and continue with the next.

It rather waits for timeout and reconnect.
OngL is offline  
Old 08-05-2004, 11:29 AM   #6
Outlaw
Junior Member
 
Join Date: Aug 2004
Posts: 5
Default

Just to clarify this is when i am uploading files to another site. All files that i download from various places work fine. Also didn't matter if i was uploading to a site pasv , or ssl or tls.
Outlaw is offline  
Old 08-05-2004, 11:53 AM   #7
Harm
Too much time...
Ultimate Scripter
 
Join Date: Jul 2003
Posts: 1,430
Default

When you are uploading/downloading files you have 2 connections to the server. One control connection to send command and receive replies from the server and one data connection to send/receive files.
Sending NOOP during transfers (which is another option than sending NOOP when you are idling) helps to keep the control connection open. Indeed, the control connection can timeout during the file transfer and thus FlashFXP can't send the command to send/retrieve the next file and is forced to reconnect.
Harm is offline  
Old 08-05-2004, 11:57 AM   #8
Outlaw
Junior Member
 
Join Date: Aug 2004
Posts: 5
Default

I believe this thread also pertain to this problem.

http://forum.flashfxp.com/showthread...&threadid=4741
Outlaw is offline  
Old 08-05-2004, 03:28 PM   #9
MxxCon
Super Duper
FlashFXP Beta Tester
 
Join Date: Oct 2001
Location: Brooklyn, NY
Posts: 3,881
Default

Quote:
Originally posted by OngL
NOOP helps when there is no activities, we are referring to after file download completed, FFXP should have detected it and continue with the next.

It rather waits for timeout and reconnect.
flashfxp does detect when file transfer is over and goes on to the next one.
flashfxp waits for the server to reply back saying that it recieved everything and it's ok to continue.
if your control connection times out or gets closed then obviously there is no way for flashfxp to know that the transfer is over.
__________________
[Sig removed by Administrator: Signature can not exceed 20GB]
MxxCon is offline  
Old 08-14-2004, 11:35 AM   #10
Outlaw
Junior Member
 
Join Date: Aug 2004
Posts: 5
Default

Still doing the same as i stated above and its not a problem with the older version of flash which is what i am about to reinstall since my frustration level have peaked with this newer version, i have even spoken to someone on the tech support side for flashfxp. others seem to be having this problem i wonder if they have found out a solution?
Outlaw is offline  
 

Tags
file, ftp, ftps, fxp, [r]

Thread Tools
Display Modes

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is Off
HTML code is Off

Forum Jump

Similar Threads
Thread Thread Starter Forum Replies Last Post
3.7.0 Known bugs darkone Bug Reports 6 12-10-2002 07:21 PM


All times are GMT -5. The time now is 12:49 AM.

Parts of this site powered by vBulletin Mods & Addons from DragonByte Technologies Ltd. (Details)