World: r3wp

it completes :)

i'll have to print timestamps to even get an idea how long that stalls 
:)

but now i know that it's 150 for when the transfer starts and 226 
when it finishes

150 is just a mark ... comment

ok

all those can be ignored

can you email the new version?  mine is corrupted now ...with the 
manually applied diff's!

Or upload it ... using the credentials I sent you.

sec, still debugging

closed 12-Jan-2010/2:48:18+1:00
fin 12-Jan-2010/2:51:18+1:00

wow, stalls for precisely 3 minutes

ah, found it

it takes two to takedown a TCP connection

i.e. even if the server closes it's side, until the client also closes, 
the connection is still open

or even more plainly: in the dataport's close handler, you need to 
close the port as well

I close cmd ...

oh ... I read that I don't need to close the port ...

oh .. misunderstood ... what I read

if the dataport is closed on you, you need to close it as well

Clients closing connections


The client can simply close the connection without sending QUIT. 
This saves time and memory for both the client and the server.

There are a few broken TCP implementations, such as MacTCP 2.0.6, 
that fail to acknowledge TCP FINs after a local close. If the client 
is running on such a host, it shouldn't close the connection until 
after it sends QUIT and sees the server close the connection; otherwise 
the server will waste time repeatedly transmitting the FIN until 
it times out.

ok, need to close

must be why when I login to chat .. .I start getting more messages 
from my ftp handler!

here's the updated version (i also bumped the version number): http://bolka.at/share/prot-ftp.r, 
here's the full diff to 0.0.5: http://gist.github.com/274796

there's also a lovely gem contained in that code, btw

your dataport is never WAITed on

as there's a WAIT on the ftp scheme port already, simply OPENing 
the dataport suffices to have it scheduled and receiving events

ahh... I wondered how that worked

Impressive .. it works fast!

yes

and that with all the debug output

das RETR take full paths?

for where?

I don't know if the ftp server will take a full path but the client 
can

could i have a minimal FTP thingie with just USER/PASS/PASV/RETR?

TYPE

TYPE I would be needed as well

yes

I don't know if the server will accept a path ...

i'll try :)

try it ..

should work, iirc

yeah, works fine

great ...

and you can just queue commands with the WRITE

dunno if two consecutive RETR wil work though

you'll at least need another PASV before the 2nd RETR

Does the WRITE set off the handler again?

guess it needs another read ..

from within the awake handler: yes

from the outside: no