It's not a secret anymore!
The moose likes I/O and Streams and the fly likes Checked streams Big Moose Saloon
  Search | Java FAQ | Recent Topics | Flagged Topics | Hot Topics | Zero Replies
Register / Login
JavaRanch » Java Forums » Java » I/O and Streams
Bookmark "Checked streams" Watch "Checked streams" New topic

Checked streams

Tim Deborg

Joined: Aug 23, 2007
Posts: 6

I'm trying to create a checksum in an applet and send it to the servlet where it can be compared.

I'm having this code:

//mail is a MimeMessage object: a mail containing a bit of text and an attachment and a signature
URLConnection connection = getConnectionToServlet();
OutputStream emptyOutput = new OutputStream(){
public void write(int b) throws IOException {

CheckedOutputStream checkedOut = new CheckedOutputStream(emptyOutput,new CRC32());
System.out.println("mail checksum over empty-output: "+checkedOut.getChecksum().getValue());
out = connection.getOutputStream();
CheckedOutputStream checkedOut2 = new CheckedOutputStream(out,new CRC32());
System.out.println("mail checksum over real-output: "+checkedOut2.getChecksum().getValue());

and it gives me the following output:
applet checksum over empty-output: 472918629
applet checksum over real-output: 2979688346

How can this be possible?? I would expect the checkedOutputStream would just take bytes, update checksum and at send bytes to the wrapped stream?
Can someone explain how this is possible?

when I put that code in a loop, I get results as:
applet checksum over empty-output: 472918629
applet checksum over real-output: 2979688346

applet checksum over empty-output: 1455969375
applet checksum over real-output: 2957360115

applet checksum over empty-output: 1607214671
applet checksum over real-output: 1607214671

So sometimes the checksum is the same... I do not understand.
Peter Chase
Ranch Hand

Joined: Oct 30, 2001
Posts: 1970
When the checksums are different, are the bytes the same? That's the test you need to do.

Betty Rubble? Well, I would go with Betty... but I'd be thinking of Wilma.
Tim Deborg

Joined: Aug 23, 2007
Posts: 6

Just checked and there seems to be some different bytes in the signature part of the mimemessage. Which is strange I would think because It's just the same object being written to a stream.

Even if I put the code that writes to an empty string in a loop, the result is most often different.

If someone has a clue about for what reason the bytes can change, ...
This is hard to debug (the signed part), but I will have to try. Tomorrow.

Jim Yingst

Joined: Jan 30, 2000
Posts: 18671
I don't know what's going on here, but I would try writing the message to System.out or to a file, and then looks at it (as text) to see if you can determine which header value is different. The name and value of the header can be important clues here. Perhaps something is auto-generating a new content ID, or a timestamp. Note that you can tell writeTo() to ignore certain headers - see writeTo(OutputStream, String[]).
[ August 23, 2007: Message edited by: Jim Yingst ]

"I'm not back." - Bill Harding, Twister
Tim Deborg

Joined: Aug 23, 2007
Posts: 6
it's not one of the headers, it's a couple of bytes that differ in the signature part in the EML.

Tim Deborg

Joined: Aug 23, 2007
Posts: 6
I added
properties.put("mail.mime.cachemultipart", "false");
to the javamail session properties and guess what?
It works on the servlet I use but it does not work on the applet :s
I also tried javamail 1.4, 1.1, 1.3.2, 1.4.1ea but no result.

I got my inspiration here:
The property should make sure the multipart is not reencoded when sending to the stream, but it seems not to work in my applet...
I agree. Here's the link:
subject: Checked streams
It's not a secret anymore!