World: r3wp

I think that might help with directory parsing ...

made the last "read client" in the read event handler block conditional:
unless client/spec/ready [read client]

in case it's an Amiga ftp server ...

:)

returned "client/spec/ready" instead of "false" from the awake

one problem remains: the read after RETR does not return

hmm... my 0.0.5 added a return true

on a successful download

so just comment out line 261 ?

write-cmdport/only client [SYST]

so where do I set the state then?

here's a diff of my changes: http://gist.github.com/274796

that's a diff against the 0.0.5 from wik.is

wow .. you managed to nuke my 'read !

hehe :)

now what's expected sequence on the cmd connection for RETR?

ah!!

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