AS3 FTP Programming and the Socket and ByteArray Classes?

The FTP protocol predates UTF encoding. Switch to ANSI/ASCII for better results. If you do opt for writeMultiByte instead of writeUTFBytes, be aware that it is buggy in linux Here's one way around it There's another question here where the line ending turns out to be the culprit, so make sure that you get it right (as suggested above) As said before, if this is running from the web, all socket connections will require a crossdomain policy, but this is NOT file based over HTTP.

Recent changes to the security rules mean that any socket based connection must first get a crossdomain from a policy server hosted on port 843 of the target host Quoting from Adobe: A SWF file may no longer make a socket connection to its own domain without a socket policy file. Prior to version 9,0,115,0, a SWF file was permitted to make socket connections to ports 1024 or greater in its own domain without a policy file HTTP policy files may no longer be used to authorize socket connections. Prior to version 9,0,115,0, an HTTP policy file, served from the master location of /crossdomain.

Xml on port 80, could be used to authorize a socket connection to any port 1024 or greater on the same host Essentially, what this means is that you must be in control of the target FTP host, and install supplementary software on it to get this working.

The FTP protocol predates UTF encoding. Switch to ANSI/ASCII for better results. If you do opt for writeMultiByte instead of writeUTFBytes, be aware that it is buggy in linux.

Here's one way around it. There's another question here where the line ending turns out to be the culprit, so make sure that you get it right (as suggested above). As said before, if this is running from the web, all socket connections will require a crossdomain policy, but this is NOT file based over HTTP.

Recent changes to the security rules mean that any socket based connection must first get a crossdomain from a policy server hosted on port 843 of the target host. Quoting from Adobe: A SWF file may no longer make a socket connection to its own domain without a socket policy file. Prior to version 9,0,115,0, a SWF file was permitted to make socket connections to ports 1024 or greater in its own domain without a policy file.

HTTP policy files may no longer be used to authorize socket connections. Prior to version 9,0,115,0, an HTTP policy file, served from the master location of /crossdomain. Xml on port 80, could be used to authorize a socket connection to any port 1024 or greater on the same host.

Essentially, what this means is that you must be in control of the target FTP host, and install supplementary software on it to get this working.

He could go through his own host to avoid that. – Wouter Lievens Jan 26 '09 at 19:33 I agree, but have never been in a position to shoulder the bandwidth that this would incur – spender Jan 27 '09 at 7:04.

Read this link too and maybe it can be useful this one too. The first one is about policy files and the second is an example of a TELNET (so, no FTP here) client.

We will need more info to resolve this.. What you're saying here appears correct to me. You're using the Socket class to send data though, not ByteArray. Are you sure data is not being sent?

How are you receiving the response? It may be that it's working fine but you're just not aware of it? As I said, tell us more about what you're doing.. Lee Brimelow has a screencast on gotoAndLearn of writing an POP3 client.It's essentially the same of what you're doing so take a look.

I know with HTTP you'll have to an include extra linebreak after the request for it to go through. Without it you'll get nothing back. Not sure how it is with FTP though.

The FTP standard requires CRLF at the end of commands. Try using "\r\n" in place of the "\n" in your example.

You must serve the CrossDomain Policy File from your FTP server in order to conect correctly.

From what I've gathered, you have to send each command one at a time and validate the response before moving on. You should be getting something back against ProgressEvent. SOCKET_DATA Try just this and see what you get in response.Socket.

WriteUTFBytes("USER "+user+"\n"); socket.flush(); You would then read the response out like this. Var response:String = mySocket. ReadUTFBytes(mySocket.

BytesAvailable).

I've been able to get an FTP client working in a browser, but it's buggy. I had to get a listener running on port 843 to server the policy file so that Flash would be allowed to connect and transfer data. Then, I had to figure out how FTP actually works: You have to open 2 sockets: a command socket and a data socket.

The command socket is where you send your USER, PASS, CWD, and STOR commands. The data socket is where you write your ByteArray data to. Sending the PASV command will tell you what port your data socket must connect to.

Where it is buggy is on Mac, in both Safari and FF, when I call the "socket.close()" command, the server socket actually closes. On Windoze, it does not. This is a huge problem because the Event.

CLOSE event is not fired until the SERVER closes the connection. This is in the livedocs. This is where I'm at.

I have no idea why it would work flawlessly on Mac and then be completely busted in 3 different browsers on Windows. The only thing I can come up with is that it's either something in my Windows configuration that's preventing proper communication with the server, or it's the Window Flash player that's causing the problem. Any thoughts?

The FTP protocol predates UTF encoding. Switch to ANSI/ASCII for better results. If you do opt for writeMultiByte instead of writeUTFBytes, be aware that it is buggy in linux.

Here's one way around it.

Read this link too and maybe it can be useful this one too.

I cant really gove you an answer,but what I can give you is a way to a solution, that is you have to find the anglde that you relate to or peaks your interest. A good paper is one that people get drawn into because it reaches them ln some way.As for me WW11 to me, I think of the holocaust and the effect it had on the survivors, their families and those who stood by and did nothing until it was too late.