World: r3wp

seems like a lot of overhead too ...

i tested. Alternating read/write causes the buffer cleared each times

so the docs are correct

But the buffer is cleared only after a write action occured .

If you receive several read events the data are added to the buffer 
(buffer not cleared)

Yep, I think that's what I said above

ok, i just confirmed it with tests

i encountered the famous stack overflow bug.

Never never use a [wait] when you treat an event in the awake handler

I see in Gabriele's prot-http he has an http-awake handler that creates 
events which he passes on to another awake handler

yes but it"s fake events passed from tcp port thru the fake http 
port.

Actually, it's just calling the event handler function of the fake 
port

it's not asynchronous

it's a pity that we have to "fake" these events, currently

I'd love to be able to pass "real" events on, WAKE-UP would already 
be there, but other stuff seems to be missing

i tried sending with WAKE-UP from the tcp port to the scheme port, 
and the scheme port's AWAKE handler even got called

but a WAIT on the scheme port never returns, even though the scheme's 
AWAKE returns true

anyone can test this http://rebol.wik.is/Rebol3/Schemes/Ftp

the default timeout times out waiting for ftp.debian .. so I put 
a wait 10 seconds there!

I was trying to find a ftp site with a lot of data to read from ...

I may have some redundant waits there in the handler

try /debian/pool/main/x/ instead of /debian/dists/lenny/

that should give you a huge directory listing :)

ok

eeek... r3alpha crashed on me :(

heh :)

yeah ..doesn't get a complete directory listing ...

something must be wrong in my dataport event handler

missing a read port in the read event

only picks up 5355 bytes

I can pick up the rest doing a 
read cmd

sounds like it should be

...

i think with PASV you should just re-read on the data port until 
the port is closed, no?

i just tried a bit from the console

i got LIST reponse for /debian/pool/main/x with two read events

first returned 32000 bytn

bytes*

second appended another 13901 bytes

Does the server always close the dataport after sending data?

if so I can keep trying to read until the port is closed

yes, that's how PASV works, as far as i know

client sends PASV, gets a port number, connects to that port

client/spec/dataport/awake: func [event /local port] [
											port: event/port
											print ["==TCP-event on dataport:" event/type]
											switch/default event/type [
												read [print ["^\read:" length? port/data] 
													print to-string port/data
													clear port/data
													read port
												]
												wrote [read port]
												lookup [print query port open port]
												connect [read port]
												close [ ]
											][true]
										]

yep

so this is my data port handler ..

if you really want to collect the response, drop the CLEAR

and then store port/data away in the close event

let me try that

you'll have to do a PASV before each new request

to avoid that, there was APSV ("all passive"), dunno how support 
for that is

Still needs two reads

yeah, that's ok, no?