Fairly complex one this.. not expecting answers as such.. but kinda voicing my problem incase any one else found the same issue, is it a bug ? Is it a feature ?
I am using CRC checksums on bytes arrays containing AMF serialised objects to see if the two objects are the same. The objects I am using a simple dynamic objects... ie.
myObject = new Object();
myObject.foo = "bob";
myObject.subObject = new Object();
myObject.subObject.barfoo = "Harry";
However what I've found is that the writing and reading an object from a byteArray is not a perfect mirror. If I write an object to a byte array , then read it back ,though the object looks the same, its different. You can tell this because if you write the re-constructed object to another byteArray you end up with a different sequence of bytes. This probably does not effect most people, the object itself behaves exactly as before, but because I am running a CRC checksum on the byteArrays to see if the objects are different, they are comming up different ( some of the time ) even though I hav'nt changed the content. Looking directly at the byteArray data you can see that the bytes are the same, just shuffled.
//Construct byte array, and write my object to it.
var testBytesA:ByteArray = new ByteArray();
testBytesA.writeObject( myObject );
testBytesA.position = 0;
//Calculate checksum... and trace ( You can check the bytes one by one if you like.. )
trace( Crc32.instance.crcByteArray(testBytesA).toString() );
//Re-construct an object from bytes
var testObjectA:Object = testBytesA.readObject();
// Now write object out again into a byte array.
var testBytesB:ByteArray = new ByteArray();
testBytesB.position = 0;
//Calculate checksum... and trace
var crcB:String = Crc32.instance.crcByteArray(testBytesB).toString();
The two checksums quite often differ.. I did also trace out the entire byteArray to discover that the byteArrays content is the same but shuffled. Repeating serialisation of the same object gives the same byteArray.. which leads me to believe its the readObject() that is at fault.
Is this a bug? It does mean I'm going to have to use a rough checksum ( parity / modal sum ) .. .unless the powers at Adobe see fit to adjust their readObject() method...
I'm guessing that the properties of the object are written in different orders during serialization. This would explain why the objects behave the same, and why the byte array contains the same data but appears to be shuffled.
Agreed.. though if I run the writeObject() multiple times on the same object I do get a consistant byteArray serialisation which is what makes me think its more to do with the readObject.But I've got round it for now...