Go Back   FlashFXP Forums > > > >

Bug Reports Report bugs here. (non-beta releases only)

 
 
Thread Tools Display Modes
Old 05-18-2002, 05:40 PM   #1
robe
Junior Member
FlashFXP Registered User
 
Join Date: May 2002
Posts: 4
Default quit handling while in file transfer

hi!

it seems as if flashfxp (build 836 over here) doesn't handle quits correctly while transferring a file

if you press "disconnect" while transferring a file, flashfxp waits till the send buffer is emptied, then dispatches a "quit" to the server (which arrives at the serverside) and then immediately kills the control connection, leaving the server no chance to send the 221 response, which will result in a ghost connection on the server side.

this was testet with proftpd 1.2.5rc2
robe is offline  
Old 05-18-2002, 06:08 PM   #2
MxxCon
Super Duper
FlashFXP Beta Tester
 
Join Date: Oct 2001
Location: Brooklyn, NY
Posts: 3,881
Default

that's why you should use ABORT and then disconnect.

in some cases you actualy have to just drop connection, so think current way is fine.

and btw, upgrade alot of things were improved since 835.
MxxCon is offline  
Old 05-18-2002, 06:36 PM   #3
robe
Junior Member
FlashFXP Registered User
 
Join Date: May 2002
Posts: 4
Default

it's not fixed in 849 either..

the current behaviour is a violation of the rfc so it can't be right (when there's no transfer running flashfxp "behaves" right, waiting for the 221 response from the server before killing of the control connection).

i agree with you that there may be situations where you just want to kill of the data connection (e.g. remote server went dead); what about making the first click on "disconnect" a soft disconnect, and the second abruptively closing the data and control connections?
robe is offline  
Old 05-18-2002, 07:03 PM   #4
bigstar
FlashFXP Developer
FlashFXP Administrator
ioFTPD Beta Tester
 
bigstar's Avatar
 
Join Date: Oct 2001
Posts: 8,012
Default

Quote:
Originally posted by robe
it's not fixed in 849 either..

the current behaviour is a violation of the rfc so it can't be right (when there's no transfer running flashfxp "behaves" right, waiting for the 221 response from the server before killing of the control connection).
I'll look into that.

Quote:
i agree with you that there may be situations where you just want to kill of the data connection (e.g. remote server went dead); what about making the first click on "disconnect" a soft disconnect, and the second abruptively closing the data and control connections?
That's exactly how it works. The first click sends QUIT, the second forces disconnect.
bigstar is offline  
Old 05-19-2002, 12:15 AM   #5
Jesper
Senior Member
 
Join Date: Dec 2001
Posts: 119
Question Question

About this "ghost" problem there obviously is in FFXP

Could the problem also occur if the client looses his connection e.g pings/times out ? and that way leave a ghost on the FTPd that he is uploading to ?
Jesper is offline  
Old 05-19-2002, 09:03 PM   #6
MxxCon
Super Duper
FlashFXP Beta Tester
 
Join Date: Oct 2001
Location: Brooklyn, NY
Posts: 3,881
Default

yes, it's possible if connection didn't time out soon enough.
many ftpd support special login something like "-username" or "username!" that will kill ghost connections.
MxxCon is offline  
Old 05-19-2002, 11:13 PM   #7
bigstar
FlashFXP Developer
FlashFXP Administrator
ioFTPD Beta Tester
 
bigstar's Avatar
 
Join Date: Oct 2001
Posts: 8,012
Default Re: quit handling while in file transfer

Quote:
Originally posted by robe
it seems as if flashfxp (build 836 over here) doesn't handle quits correctly while transferring a file
After further investigation you appear to be correct, I'm not entirely sure why but the code that sends abort on disconnect was commented out. I have re-activated it.
bigstar is offline  
 

Tags
connection, file, quit, send, server

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 On
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 03:05 PM.

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