Forum ‹ C# ‹ Endianness

[Kikkers]

Hi there,

I have just started experimenting with the byte array transmission between the client and server, trying to figure out how to transmit the smaller data types to reduce bandwidth.

I noticed the endianness of C# and actionscript seem to be the inverse of eachother on my system, which i can work around, but I need to know if the endianness might change if I run my code on the Player.IO servers. I'm testing my endianness on the servercode with BitConverter.IsLittleEndian, but since this is system based, i can't set this value.

Knowing this now could save me some headaches later on.

[Oliver]

Hey,

First of all, if you want to save traffic, you shouldn't try to pack everything into a bytearray. Just add integers, bool, strings etc directly to the message. We're doing a lot of work to only send as few bytes as possible over the wire. For instance, if you send an integer with a value between 1-127 it will only take 1 byte across the wire, even though an int is 4 bytes.

In terms of endianness... If you do as mentioned above you won't have to think about it. You're right that C# and Flash are different, but it's more complicated than that: you have to think about machine-endianess (this is what's exposed in C#) and network-endianess, which differs... sometimes....

In general, if you want to do this sort of thing, you'll have to check the property you mentioned, and have code that works with both cases.

Currently all our game servers are Intel machines, and i don't think that'll change, so i'd propose you just have your game write a message to the ErrorLog if it detects it's running on a machine with unexpected endianess...

Hope this helps a bit.

Best,
Oliver

[Kikkers]

Exactly the answer i was looking for, and more even

Looks like i'll be switching methods.

One related question,
Because of flash's data type limits, it might be hard to discern the difference in precision i need (float / double). Hence the reason i was trying bytearrays.
Is anything similar happening there in Player.io?

As a reference, in my application, i suspect i won't need more than float precision.

[Oliver]

I don't fully understand the float/double question. Can you restate it?

[Benjaminsen]

As you point out yourself, determining the best encoding format can be complex from Flash. The result is that we encode the data as optimally as we can, then typecast it to the requested type on the server.

Can be encoded as single char int > encode as short int > else
Can be encoded as short int > encode as short int > else
Can be encoded as int > encode as int > else
Can be encoded as float > encode as float > else
Can be encode as Double > encode as double

Thus, even though the Number class is ambiguous we always encode optimally.

[Kikkers]

Yes, that's what i meant.

So when I send a decimal Number, i can expect player.io to send it as a float as long as the variable is small/imprecise enough. Sounds simple enough to use.

Thanks for all your effort, I'm liking the product so far and i'm curious to see what i can make it do

[Benjaminsen]

So when I send a decimal Number, i can expect player.io to send it as a float as long as the variable is small/imprecise enough. Sounds simple enough to use.

Exactly, for almost all cases the build in encoding is more than adequate.

[markloika]

If you want to always send byte arrays to the client in a particular endian, you can do what I did in this function:

Code: Select all

        public byte[] ribbonBytes()
        {
            List<byte> bytes = new List<byte>();

            for (int i = 0; i < ribbonList.Count; i++)
            {
                byte[] intBytes = BitConverter.GetBytes(ribbonList[i]);

                if (BitConverter.IsLittleEndian)
                {
                    Array.Reverse(intBytes);
                }

                bytes.AddRange(intBytes);
            }

            return bytes.ToArray();
        }


ribbonList is a List<int>, and it's being encoded into a byte[] in big endian (regardless of the endian of the server).

Big endian vs little endian is quite simple. Little endian means that 'little comes first', so a 32 bit int (4 bytes) would be ordered in this way: byte 0, byte 1, byte 2, byte 3 when using BitConverter.GetBytes(myInt32). Big endian means 'big comes first', so the byte array created by BitConverter.GetBytes(myInt32) will be arranged in the opposite order: byte 3, byte 2, byte 1, byte 0. By detecting which endian the server is, you can just reverse the array (or not) of the byte array.

[jasonMcIntosh]

You could also just send strings and then parse them back to the numeric type on the other end.

[markloika]

You could also just send strings and then parse them back to the numeric type on the other end.

While functional, that would use the most bandwidth of any solution.