World: r3wp

7zip opens it up ..

great

Uploaded my latest version which by default downloads ubi.exe which 
is a 1.5mb file ( ubuntu windows installer. )
You can uncomment the 650 mb download if you want to try :)

we really ned to get rid of those WAITs :)

I haven't done it yet, but if one gets an error code, it should probably 
throw an error.

or maybe the server is so slow :)

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