Socket AS3 ( Receive File .TXT ) + Java Socket

Question

Hi,
I have Java Socket sending .TXT file ( 10 MB ) . But the AS3 only gets 63 Kb . I do not understand the loss of bytes ...
Souce Java :
public void sendFile(String fileName) {
        try {
            //handle file read
            File myFile = new File(fileName);
            byte[] mybytearray = new byte[(int) myFile.length()];
            FileInputStream fis = new FileInputStream(myFile);
            BufferedInputStream bis = new BufferedInputStream(fis);
            DataInputStream dis = new DataInputStream(bis);
            dis.readFully(mybytearray, 0, mybytearray.length);
            OutputStream os = clientSocket.getOutputStream();
            byte[] fileSize = intToByte(mybytearray.length);
            byte[] clientData = new byte[(int) myFile.length() + mybytearray.length];
            System.arraycopy(fileSize, 0, clientData, 0, fileSize.length); // Copy to the file size byte array to the sending array (clientData) beginning the in the 0 index
            System.arraycopy(mybytearray, 0, clientData, 4, mybytearray.length); // Copy to the file data byte array to the sending array (clientData) beginning the in the 4 index
            DataOutputStream dos = new DataOutputStream(os);
            //dos.writeUTF(myFile.getName());
            //dos.writeInt(mybytearray.length);
            dos.write(clientData, 0, clientData.length);
            dos.flush();
AS3 Source..
private function onResponse(e:ProgressEvent):void {
  var file:File;
  var fs:FileStream;
  var fileData:ByteArray = new ByteArray();
  file = File.documentsDirectory.resolvePath("tmpReceive.txt");
  fs = new FileStream();
  fs.addEventListener(Event.CLOSE,onCloseFileReceive);
if(_socket.bytesAvailable > 0) {
  while(_socket.bytesAvailable) {
  // read the socket data into the fileData
  _socket.readBytes(fileData,0,0);
  fs.open(file, FileMode.WRITE);
  // Writing the file
  fs.writeBytes(fileData);
  fs.close();

Answer 1

Crypto streams, like CipherInputStream andCipherOutputStream, do not behave properly until you
issue a close() call. So if you are going to do
crypto, you will need to trap the close() before it
reaches the underlying socket streams. This is
because the close() method finalizes the cryptographic
operation. (Flush() would make more sense, no idea
why they did it this way). You do want to finalize
the crypto for any given message, but you need to trap
the close() before it hits the socket and ends the
whole affair.
I don't see anything about that in the bug database.
No matter what streams you are using, if you aregoing to keep the socket open for multiple
request-response round-trips, you need to very closely
pay attention to how much data is being sent on each
trip. Normally, you can fudge this a bit on a
request-response because the close() call on the
output stream will cause the receiving input stream to
behave more or less properly. However, a flush() will
not.Why not? I use that all the time with no problem.
A good practice is to send the content-length of
the message first, so the receiving input stream
"knows" when to stop reading, does not block, and then
can send its own bytes back the other direction.
(Where the process is repeated).
An alternative is to use two threads: read and write.
The read recieves, parses, validates and then pushes complete messages to a queue.
The write pulls messages from the queue, processes and send a result.
A variation to the above is what happens when an invalid message is received. The server can ignore it, the read can send a error response, or the read can push a message to the queue which causes the write to send a error response.