🚀 go-pugleaf

"Alan Shiers" <ashiers@hfx.eastlink.ca> wrote in message
news:3D21C1CA.F2D953E2@hfx.eastlink.ca...
> 1) On the client-side app I read the size of the file and send out the
> file size value to the server app via DataOutputStream. I then fill a
> byte array with the entire file on the client-side app.
>
> 2) Then I use a for loop to send the contents of the file, one byte at a
> time, out through the DataOutputStream.

I would change these so the read and write happen simultaneously.
Something like this:

    int c;
    while ((c = in.read()) != -1)
      out.write((byte)c);

Now there's no buffer, and your process only needs to remember one byte at
a time.  Then I'd change this again to do the same thing but in blocks of N
(ex. N=64 or N=128) bytes instead of one at a time.

    byte[] buffer = new byte[128];
    int n;
    while ((n = in.read(buffer)) >= 0)
      out.write(buffer, n);

> 3) On the server-side app I receive the file size value via
> DataInputStream and dimension a byte array to accomodate the incoming
> file.
>
> 4) I use a for loop to retieve the contents of the file via
> DataInputStream one byte at a time on the server-side app.

Do the same thing on the server.  Read small chunks and write them out to
the destination file.

> Maybe I should be using a Vector instead of dimensioning a byte array
> everytime?

That would probably be worse.  Vectors can only contain objects, not
rudimentary data types, so what is now a byte or int would need to be a
Byte or Integer instead.  Objects take up more memory, so you'd actually
run out of memory sooner this way.

> Taking my four step algorithm above, how would you change it to safely
> download large files?

See above.

> Should the changes I make be only on the server side or should I
> implement a change at both ends?

Both sides.  The sever might be a more powerful machine with more memory,
but the fundamental problem will still exist on both sides.  No matter how
much memory the machine has, there will always be some giant file size that
will cause you to run out.  If you process more manageable chunks of data,
then you can essentially eliminate this problem (as long as you have at
least 256 bytes of memory :-).

--
Gillmer J. Derge [TeamB]