World: r3wp

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?

switch/default event/type [
												read [print ["^\read:" length? port/data] 
													read port
												]
												wrote [read port]
												lookup [print query port open port]
												connect [read port]
												close [ print to-string port/data]
											][true]

so keep reading until the port is closed ...

exactly

well, gotta run now. good luck!

ok,

they must be sending me two lots of data

40k+ for the LIST in pool/x

a good test :)

and it's good to know that data is appended

saves me the separate buffer in my pop3 prot

and the buffer keeps expanding too

Using a timeout value, largish, I can read a 5000 file listing in 
a ftp directory.  Posted latest code.

It sounds to me that the timeout is counting down while you are receiving 
data. That's not logical?

Henrik ..I have little idea of what I'm doing .. just stumbling around 
here.

Downloaded a 16Mb file using my ftp scheme ... streamed it to disk 
directly rather than saving in any buffer.

Changed the format of the data block a little ...

write cmd [ RETR "REMR.zip" %remr.zip]
read cmd

I'm not using a dialect but if the last member of the block is a 
file, it streams the data to the file, if it's a binary eg. a buffer, 
it appends to the buffer, and if it's a  function, then uses a the 
function as a callback on the data ...

does that sound sensible?

not bad :-)

using a function means you can pass your own directory parser to 
the incoming data to format it as you like.

Graham, regarding all the overlapped words. I am/was confused too. 
I created a sequence diagram and posted it via my homepage/blog. 
Maybe it helps, and if, please provide information about errors in 
it.

and the link is ?

http://www.robertmuench.de/blog/files/r3_ports.php

Let Carl see that diagram or put it in the wiki.

Why choose the napkin style? heh

Robert, where's the source to the http://www.websequencediagrams.com/
 you used?

Brian, how can we over ride the existing schemes?

I like the napkin style most.

I sent you the source via email as AltMe doesn't handle OSX line 
breaks.

BTW: I'm going to redo the diagram using yworks yEd editor. It's 
a fantastic graph layout editor and now supports swimlane diagrams.

Thanks Robert .. I got it

http://rebol.wik.is/Rebol3/Schemes/Ftp

Updated so that you can supply a callback to commands

eg: 

[ LIST (:print) ]

or 

[RETR "hugefile" %downloads/hugefile.mov ]

or supply a file to stream a download.

there's a bug in that I don't return to console so I must be stuck 
in the awake handler somewhere.

and it's much slower than R2 so I must be abusing the waits ...