File corruption when copying over sockets

Hello, I was using a simple file copy example to copy a file across
sockets. I use a FileInputStream to read the file, then send it out
using a PrintStream. At the receiving end I read it in using an
InputStreamReader wrapped in a BufferedReader. Then I simply write this
to a FileOutputStream. However, when I do this, although it copies the
file, it seems to be corrupted and there are always +3 bytes compared to
the original. For example I copied a BMP file, it was corrupted, the
colours were off. Similarly a wave file was horribly corrupt and sounded
terrible.
Is there an obvious problem here or is it more likely just duff code
somewhere? I'm afraid none of the code below is compilable as it relies
on quite a few classes which weren't written by me.

Here is my sendfile code:

File inputFile = new File("lmao.wav"); //test file
FileInputStream in = new FileInputStream(inputFile);
//FileReader in = new FileReader(inputFile);

ps = new PrintStream(sendSocket.getOutputStream());
//ps.println(ps);

int c;

while ((c = in.read()) != -1){
ps.write(c);}

System.out.println("File sent");

And the recieving end

for(;;)
{
try
{
br = new BufferedReader(new
InputStreamReader(receiveSocket.getInputStream()));


File outputFile = new File("lmao2.wav");
FileOutputStream out = new
FileOutputStream(outputFile);

int c;

while ((c = br.read()) != -1){
out.write(c);}

System.out.println("File recieved");


}
catch (IOException err)
{ System.out.println("error recieving file");}




--
Jeffrey Spoon

"Jeffrey Spoon" <JeffreySpoon@hotmail.com> wrote in message
news:jaJ8nCFJbyVCFwfQ@nowhere.nnn...
>
>
> Hello, I was using a simple file copy example to copy a file across
> sockets. I use a FileInputStream to read the file, then send it out
> using a PrintStream. At the receiving end I read it in using an
> InputStreamReader wrapped in a BufferedReader. Then I simply write this
> to a FileOutputStream. However, when I do this, although it copies the
> file, it seems to be corrupted and there are always +3 bytes compared to
> the original. For example I copied a BMP file, it was corrupted, the
> colours were off. Similarly a wave file was horribly corrupt and sounded
> terrible.
> Is there an obvious problem here or is it more likely just duff code
> somewhere? I'm afraid none of the code below is compilable as it relies
> on quite a few classes which weren't written by me.
>
> Here is my sendfile code:
>
> File inputFile = new File("lmao.wav"); //test file
>                 FileInputStream in = new FileInputStream(inputFile);
>                 //FileReader in = new FileReader(inputFile);
>
>                 ps = new PrintStream(sendSocket.getOutputStream());
>                 //ps.println(ps);
>
>                 int c;
>
>         while ((c = in.read()) != -1){
>            ps.write(c);}
>
>            System.out.println("File sent");
>
> And the recieving end
>
> for(;;)
>             {
>                 try
>                 {
>                     br = new BufferedReader(new
> InputStreamReader(receiveSocket.getInputStream()));

Your writer is writing bytes to the stream (which makes sense for a
byte-oriented wav file) but your reader is reading characters which are not
bytes in Java.  The InputStreamReader will convert the input bytes into
characters using the default platform encoding. (At the very least you
ensure the same encoding is used from characters -> bytes as for bytes ->
characters) You probably want the bytes directly, so either use the
InputStream itself or wrap it in a BufferedInputStream.

Cheers,
Matt Humphrey matth@ivizNOSPAM.com  http://www.iviz.com/

In message <UpCdneJLnJtHq8rfRVn-1g@adelphia.com>, Matt Humphrey
<matth@ivizNOSPAM.com> writes
>
>Your writer is writing bytes to the stream (which makes sense for a
>byte-oriented wav file) but your reader is reading characters which are not
>bytes in Java.  The InputStreamReader will convert the input bytes into
>characters using the default platform encoding. (At the very least you
>ensure the same encoding is used from characters -> bytes as for bytes ->
>characters) You probably want the bytes directly, so either use the
>InputStream itself or wrap it in a BufferedInputStream.
>
>Cheers,
>Matt Humphrey matth@ivizNOSPAM.com  http://www.iviz.com/
>
>

Thanks. I changed it to:

br = new BufferedInputStream(receiveSocket.getInputStream());


but still get exactly the same problem, so it must be something
elsewhere.

Cheers.



--
Jeffrey Spoon

On Sat, 9 Apr 2005 20:54:51 +0100, Jeffrey Spoon wrote:
> I changed it to:
>
> br = new BufferedInputStream(receiveSocket.getInputStream());
>
> but still get exactly the same problem, so it must be something
> elsewhere.

Read from the original file using a FileInputStream (don't use
anything with "Reader" in the name). Send the data with an
OutputStream, not a PrintStream. Receive the data with an InputStream.
Write the new file with a FileOutputStream (not any "Writer"). Use
Buffered versions of the various Streams if you want.

/gordon

--
[  do not email me copies of your followups  ]
g o r d o n + n e w s @  b a l d e r 1 3 . s e

On 4/8/2005 at 8:50:17 PM, Jeffrey Spoon wrote:

>      ps = new PrintStream(sendSocket.getOutputStream());

>      ps.write(c);}

In addition to what Matt said, there is no reason to be using a
PrintStream for writing binary files.  I am not sure if it will cause
problems if you only call the write(int) method, but in any case, it will
not help.

You probably just want to create a BufferedOutputStream using the stream
you get from the socket.

--
Regards,

John McGrath

In message <42583522$1@news.wineasy.se>, Gordon Beaton <not@for.email>
writes

>Read from the original file using a FileInputStream (don't use
>anything with "Reader" in the name). Send the data with an
>OutputStream, not a PrintStream. Receive the data with an InputStream.
>Write the new file with a FileOutputStream (not any "Writer"). Use
>Buffered versions of the various Streams if you want.
>
>/gordon
>

Oops, I forgot to change the PrintStream bit.

Now I receive with this:

br = new BufferedInputStream(receiveSocket.getInputStream());
File outputFile = new File("lmao2.wav")
FileOutputStream out = new FileOutputStream(outputFile);

int c;
while ((c = br.read()) != -1){
out.write(c);}

System.out.println("File recieved");

And send with:

File inputFile = new File("lmao.wav"); //test file
FileInputStream in = new FileInputStream(inputFile);
ps = new BufferedOutputStream(sendSocket.getOutputStream());

int c;
while ((c = in.read()) != -1){
ps.write(c);}

System.out.println("File sent");


The files are not as corrupt but they seem to be about 200 bytes short
now. Hmmm. Thanks anyway, it's a lot better than it was.

However it may be due to using the loopback I think I'm going to have to
test it on separate PC's because of the way they've done the sockets so
that might be something to do with it.


Thanks



--
Jeffrey Spoon

On Sat, 9 Apr 2005 22:15:30 +0100, Jeffrey Spoon wrote:
> The files are not as corrupt but they seem to be about 200 bytes
> short now. Hmmm. Thanks anyway, it's a lot better than it was.
>
> However it may be due to using the loopback I think I'm going to
> have to test it on separate PC's because of the way they've done the
> sockets so that might be something to do with it.

I suspect it has to do with the way you're closing the OutputStreams,
either when you've finished sending the file, or when you've finished
writing it to disk.

/gordon

--
[  do not email me copies of your followups  ]
g o r d o n + n e w s @  b a l d e r 1 3 . s e

In message <4258de0e$1@news.wineasy.se>, Gordon Beaton <not@for.email>
writes
>On Sat, 9 Apr 2005 22:15:30 +0100, Jeffrey Spoon wrote: 
>
>I suspect it has to do with the way you're closing the OutputStreams,
>either when you've finished sending the file, or when you've finished
>writing it to disk.
>
>/gordon
>

You're probably right. We tested it over 2 PC's the other day and it
does work - almost. The sending PC will send everything and then finish
with "file sent" and the receiving PC will take almost everything but
finish too early - then it will just wait forever for the rest of the
file. So I would assume the sending PC is closing too early. The file
appears to be about 3 bytes short.

Interestingly we limited it to send nothing but the receiving PC still
received 3 bytes. Not sure what is happening there, but could explain
why there was -3 or +3 bytes before.



--
Jeffrey Spoon

On Wed, 13 Apr 2005 14:45:42 +0100, Jeffrey Spoon wrote:
> You're probably right. We tested it over 2 PC's the other day and it
> does work - almost. The sending PC will send everything and then finish
> with "file sent" and the receiving PC will take almost everything but
> finish too early - then it will just wait forever for the rest of the
> file. So I would assume the sending PC is closing too early. The file
> appears to be about 3 bytes short.
>
> Interestingly we limited it to send nothing but the receiving PC still
> received 3 bytes. Not sure what is happening there, but could explain
> why there was -3 or +3 bytes before.

I'd suggest posting your real, complete code.

/gordon

--
[  do not email me copies of your followups  ]
g o r d o n + n e w s @  b a l d e r 1 3 . s e

In message <4258de0e$1@news.wineasy.se>, Gordon Beaton <not@for.email>
writes
>On Sat, 9 Apr 2005 22:15:30 +0100, Jeffrey Spoon wrote: 
>
>I suspect it has to do with the way you're closing the OutputStreams,
>either when you've finished sending the file, or when you've finished
>writing it to disk.
>
>/gordon
>

Yes it was my stupid fault, I wasn't closing the stream after sending
and the server was resetting because of it.



--
Jeffrey Spoon