World: r3wp

it seems to be working

Bo says maby some k connections needed

I cannot afford uploading MB of data now

(000032) 1/20/2007 9:16:47 AM - lechnowsky (*IP*)> 150 Opening data 
channel for directory list

(000032) 1/20/2007 9:16:58 AM - lechnowsky (*IP*)> 425 Can't open 
data connection
(000032) 1/20/2007 9:56:52 AM - lechnowsky (*IP*)> disconnected

that was filezilla.

that's normal, use passive mode

I was using passive mode in the above.

rebol tries  to open the channel and then hangs.

the error above is, that you are using active mode

that 425 is from the  server  when the firewall blocks?

the error above is from server, it expects, that you open connection 
where you will accept data from server. You don't open any, so it 
sends you this message after some time

i thought it  is  reversed, the server tries to open a connection 
back to me.

but it's true that Rebol is opening listen port, in my case it's 
Net-log: "Opening listen port 3790"

but I block incomming messages, so I cannot use active mode

The lines directly above that read:

(000032) 1/20/2007 9:16:47 AM - lechnowsky (*IP*)> PASV

(000032) 1/20/2007 9:16:47 AM - lechnowsky (*IP*)> 227 Entering Passive 
Mode (192,168,1,20,15,187)
(000032) 1/21/2007 9:16:47 AM - lechnowsky (*IP*)> CWD somedir/

(000032) 1/21/2007 9:16:47 AM - lechnowsky (*IP*)> 250 CWD successful. 
"/somedir" is current directory.
(000032) 1/21/2007 9:16:47 AM - lechnowsky (*IP*)> TYPE A

(000032) 1/21/2007 9:16:47 AM - lechnowsky (*IP*)> 200 Type set to 
A
(000032) 1/21/2007 9:16:47 AM - lechnowsky (*IP*)> LIST

(000032) 1/21/2007 9:16:47 AM - lechnowsky (*IP*)> 150 Connection 
accepted

(000032) 1/21/2007 9:16:47 AM - lechnowsky (*IP*)> 226 Transfer OK
(000032) 1/21/2007 9:16:47 AM - lechnowsky (*IP*)> CWD /

(000032) 1/21/2007 9:16:47 AM - lechnowsky (*IP*)> 250 CWD successful. 
"/" is current directory.

(000032) 1/21/2007 9:16:47 AM - lechnowsky (*IP*)> PORT (ip and port 
info here)

(000032) 1/21/2007 9:16:47 AM - lechnowsky (*IP*)> 200 Port command 
successful
(000032) 1/21/2007 9:16:47 AM - lechnowsky (*IP*)> CWD somedir/

(000032) 1/21/2007 9:16:47 AM - lechnowsky (*IP*)> 250 CWD successful. 
"/somedir" is current directory.
(000032) 1/21/2007 9:16:47 AM - lechnowsky (*IP*)> TYPE A

(000032) 1/21/2007 9:16:47 AM - lechnowsky (*IP*)> 200 Type set to 
A
(000032) 1/21/2007 9:16:47 AM - lechnowsky (*IP*)> LIST

If I setup my firewall to accept incomming connections, I got:
Net-log: "150 Opening data channel for directory list."
Net-log: "Closing listen port 3797"
Net-log: "Closing data port 69.12.157.73 3797 62038"
Net-log: [none ["226" "250"]]
Net-log: "226 Transfer OK"
Net-log: "Opening listen port 3798"
Net-log: [["PORT" port/locals/active-check] "200"]
Net-log: "200 Port command successful"
Net-log: ["TYPE I" "200"]
Net-log: "200 Type set to I"
Net-log: [["RETR" port/target] ["150" "125"]]
Net-log: "150 Opening data channel for file transfer."
Net-log: "Closing listen port 3798"
Net-log: ["low level read of " 2048 "bytes"]
Net-log: ["low level read of " 2048 "bytes"]
Net-log: "Closing data port 69.12.157.73 3798 62039"
Net-log: [none ["226" "250"]]
Net-log: "226 Transfer OK"
Net-log: "Caching cmd-port 69.12.157.73 3796 21"
== "now 22-Jan-2007/16:11:08+1:00"

From my point of view, Rebol is working with passive and active mode 
as well. What's exactly your problem?

If you upload a lot of files and sometimes get error, maybe it's 
problem with connection or something like that

My problem is that I am trying to do a remote backup of a complete 
directory that may contain thousands of files.  On a local area network, 
it always works fine (not using FTP), but when using FTP, it locks 
up seemingly at random.

what does it mean lock ups? That you cannot upload any file anymore?

I'm not certain, but it only seems to happen when backing up when 
part of the path is over wireless.  At least that is where the problem 
was detected and it is also how I've been testing it.  But then I 
noticed that the FTP server gave the 425 error at the same time the 
lockup happened.

No, by "lock up", I mean Rebol sits and waits forever for a response 
and never continues.  It never times out.

And you are using just a read and write?

Maybe you should use some more sophisticated method.

read and  write  should still work.

If you backup so many files, you should open just one connection 
and comunicate with the server. Not to open and close connections 
for every file.

Read and write is working... at least now:-)

I'm doing an open and copy on the source machine and I'm writing 
to the FTP server using 'write/binary/append

But it doesn't seem to hang up while appending to an existing file. 
 The only time I have seen it hang up is when Filezilla returns a 
425 message.

where was the download  for thesdk? Is  that  public?

What part of the SDK do you want?  The ftp-prot.r file?  I can place 
that on the FTP server under the rebol3 account.

yes, to make sure i use the same.

maybe the 425  is not handled correctly.

OK.  It's on the FTP server now as prot-ftp.r

In the root level.

A simple search doesn't find 425 anywhere in that protocol.

you may try my ftp-sync script ftp://rebol3:[rebol3-:-69-:-12-:-157-:-73]/test/ftp-sync-latest.zip 
I never used it in the real life, so maybe it's not perfect as well.

Do I replace the regular prot-ftp.r with this?

no... and I see, the zip is not complete, I uploaded complete script 
to:  ftp://rebol3:[rebol3-:-69-:-12-:-157-:-73]/test/ftp-sync_latest.r

And it certainly require some fixes

as it douesn't recognize, that the file is already uploaded and with 
same or newer date

there is just a little mess with the source and target path, as I 
was using it in the scenarie, where the target path was accessed 
thru http, it should not be difficult to fix it, but I don't have 
more time now

http://support.microsoft.com/kb/129395/could match?
with wireless port is more often in wait-state?

the last message can be located by looking for list-check, then some 
port-opening seems to happen.

Volker, this definitely seems like it could be the issue.

can you add some wait between  files in your code, to give it  time 
 to relax? just guessing.

Smooth-Copy has an adjustable wait mechanism built in, but it may 
make the overall length of the transfer too long.  I'll have to put 
some debugging statements in prot-ftp.r to see if I can isolate the 
problem and figure out how to go around it.

Thanks for the help you have given so far!

np

Pleae tell when you  find out where it hangs. Curious :)