World: r3wp

the debian server was really slow ... I had to wait 7 seconds for 
it to respond

i guess i'll try a local ubuntu mirror

but using a timeout for some reason means that it defaults to the 
timeout value ?

so every command uses the timeout .. so don't understand that

you wait [port timeout] ?

yes

strange

well try it and you may see it ...

i have a huge wait after SYST

ah, i guess i should try with the win32 r3 instead

ok, still. long wait after SYST

then after 227 PASV

yes ... shouldn't happen

ah, i think the culprit is that you WAIT inside the awake handler

I guess that's a no no ...

wow, you guys are rockin!  Thanks Steeve, for the dns2.  Funny, that's 
how my wife says my name when she wants something..."Oh Steeeeve."

someone said so, yes :)

so fish .. where's your codec ??

but changing the WAIT inside the awake to a READ doesn't change things 
:)

a system read?

unless you do something special, there's only system reads for tcp 
ports

no binding for me

even for the scheme port, there's only system read

but the system then dispatches this to the read actor

and my read actor does a wait

yeah, but inside wait-cmdport you're WAITing on the cmdport

inside write-cmdport*

fix it please :)

change line 212 from `wait cmdport` to `read cmdport`

doesn't fix the long lags, though

in fact, you can drop this line completely, i think

because a WRITE on the tcp port from within the tcp port's awake 
handler automatically re-schedules the tcp port for event handling

ok, working with line removed ..  but still delays

mhm

only chasing thru your code, atm :)

ok, the flow should be, imho:
- read WAITs on the cmdport

- if the cmdport needs to open a dataport, cmdport WAITS on dataport

port/state/connection is your cmdport, if i'm not mistaken

so i started by changing the read actor to:
		read: func [port [port!]] [
			wait port/state/connection
		]
which should break things hard :)

and yes it does, hangs after SYST

next step: tracing if your awake handler returns true in this case

wuah, huge switch :)

but, as expected, it does not :)

client/spec/ready seems to be a good flag to use as return value 
for the awake handler

unfortunatly, in the AUTH 230 handler, you set both ready to true 
_and_ issue another write

assuming that the SYST is rather worthless anyway, i drop the write

ready is set to true so I can process the SYST

i'll abuse ready is the return value from the awake handler, for 
now :)

I did this as otherwise I ended up pipelining the ftp server :(

don't they like that :) ?

not if they don't support pipelining!