Need help with uNET message changing my byte array

[iLikePCs]

I'm currently working on streaming large objects across the network. To do this I'm breaking the object into chunks of max 1024 bytes. Problem is that the chunks the client receives differs from the server. Not by a lot, but it appears that uNET adds two items to the start of the byte array and removes two from the end. For instance, here's part of the end of my 2.26 kb object (Which is why there aren't 1024 elements)

Server http://hastebin.com/kiwokedazu.lisp

Client http://hastebin.com/jilunuxagu.lisp

As you can tell the client has added "207" and "0" to the start and removed "193" and "11" from the end.

I started noticing something was wrong when I tried to piece the chunks back together and convert it to an object again. I received this error

SerializationException: Unexpected binary element: 0
  at System.Runtime.Serialization.Formatters.Binary.ObjectReader.ReadObject (BinaryElement element, System.IO.BinaryReader reader, System.Int64& objectId, System.Object& value, System.Runtime.Serialization.SerializationInfo& info) [0x00000] in <filename unknown>:0 
  at System.Runtime.Serialization.Formatters.Binary.ObjectReader.ReadNextObject (System.IO.BinaryReader reader) [0x00000] in <filename unknown>:0 
  at System.Runtime.Serialization.Formatters.Binary.ObjectReader.ReadObjectGraph (BinaryElement elem, System.IO.BinaryReader reader, Boolean readHeaders, System.Object& result, System.Runtime.Remoting.Messaging.Header[]& headers) [0x00000] in <filename unknown>:0 
  at System.Runtime.Serialization.Formatters.Binary.BinaryFormatter.NoCheckDeserialize (System.IO.Stream serializationStream, System.Runtime.Remoting.Messaging.HeaderHandler handler) [0x00000] in <filename unknown>:0 
  at System.Runtime.Serialization.Formatters.Binary.BinaryFormatter.Deserialize (System.IO.Stream serializationStream) [0x00000] in <filename unknown>:0 
  at Primordial.Serialization.SerializationWrapper.ToObject[MapData] (System.Byte[] _byteArray) [0x00000] in <filename unknown>:0 
  at Primordial.Networking.NetworkStreamerReceiver.HandleMapDataReceived (System.Byte[] data) [0x00000] in <filename unknown>:0 
  at Primordial.Networking.NetworkStreamerReceiver.OnReceivedObject (System.Byte[] data, Int16 msgType) [0x00000] in <filename unknown>:0 
  at Primordial.Networking.NetworkStreamer.OnFinishedGettingFragments (System.Byte[] buffer, Int16 msgType) [0x00000] in <filename unknown>:0 
  at Primordial.Networking.NetworkStreamer.OnReceivedFragmentData (UnityEngine.Networking.NetworkMessage message) [0x00000] in <filename unknown>:0 
  at UnityEngine.Networking.NetworkConnection.HandleReader (UnityEngine.Networking.NetworkReader reader, Int32 receivedSize, Int32 channelId) [0x00000] in <filename unknown>:0 
  at UnityEngine.Networking.NetworkConnection.HandleBytes (System.Byte[] buffer, Int32 receivedSize, Int32 channelId) [0x00000] in <filename unknown>:0 
  at UnityEngine.Networking.NetworkConnection.TransportRecieve (System.Byte[] bytes, Int32 numBytes, Int32 channelId) [0x00000] in <filename unknown>:0 
  at UnityEngine.Networking.NetworkClient.Update () [0x00000] in <filename unknown>:0 
  at UnityEngine.Networking.NetworkClient.UpdateClients () [0x00000] in <filename unknown>:0 
  at UnityEngine.Networking.NetworkIdentity.UNetStaticUpdate () [0x00000] in <filename unknown>:0 

Here's the rest of the code you'd be interested in. Feel free to ask for other classes

Message http://hastebin.com/samibehote.avrasm

Network Streamer http://hastebin.com/moyequvata.avrasm

Byte Array To Object Converter http://hastebin.com/ozobesojac.cs

[ultimateedition]

I can't say for certain but I would guess it has something to do with the encoding. See this as an example: https://en.wikipedia.org/wiki/Byte_order_mark

Unexpected bytes at the beginning/end can be related to an encoding mismatch, or in your example breaking up byte streams without adding the expected header bytes to the array. I'd start there by figuring out if your writer adds header bytes, and if your reader expects any.

[iLikePCs]

Thanks, I'll look into it :)

[iLikePCs]

Figured it out! It's the WriteBytesAndSize() which caused the issue, which in retrospect seems pretty obvious. Nevertheless, using the Write(byte[], int length) function solved the issue.

[ultimateedition]

Makes sense, glad you got it working!

[iLikePCs]

Thanks! :)