About Bytes in/out and data type sizes

edwood_grant
edited June 2010 in DotNet
Hello again, here testing with free version of photon :D

I have a question about the variable bytes in / out in the client sdks

Basically is about how what exactly represent the PhotonPeer.BytesIn Property and PhotonPeer.BytesOut Property, an how are the data type sizes representing the overhead.

The issue is that, for example I am sending from the serve this data (just as an example, I may be sending in the end about 400 bytes, maybe its too much? i dont know)
gamestate (byte)
timeleft (int)

As far as I know, this would account for 5 bytes (one byte in gamestate and 4 bytes in timeleft, according to c# data type sizes), asumming the overhead you have in other thread with the traffic calculator, i would have:
(5bytes + 52 header bytes) * 12 buffer bytes = 68 bytes
I send this data 10 times a second from server to all clients as an event, I use Publish Event for this.

Now, I asumme this value would be the one that would show up in PhotonPeer.BytesIn Property... now i see a number that is constantly going up, so I believe that is because its just adding the toal up, so i make a delta... but I am surprised to see about 204 bytes (and somtiems 252 very briefly, maybe keep alive data?)... so I end up kinda stumped.

I can do the same for ougoing commands from client to server, I am right now sending two floats to server, which are 8 bytes.
The PhotonPeer.BytesOut Property tells me I am sending 56 bytes, but if i use the traffic calculator
(52 + 8) *1.2 = 72 bytes
I should be sending more data than it shows...

Maybe I am doing something wrong? I am making this qeustion because calculating the number of bytes that are sent from the photon server each "game step" is vital for me.

Also I want to know what its the best way to send data in the hashtables,
I usually put the keys as bytes (usually from an enum in C#), adn then the data (int, floats, strings, arrays, etc)

I am also puting hastables inside hashtables because i need for example some information concerning a player only, so i create a hashtable for it, put some values and add it up to the rest of the data to send,.... maybe that is a terrible idea?

I am probably making a huge lot of mistakes because of my not-so-good experience at this. I would aprreciate a lot if you can offer me some insight about it.

Thanks a lot,

Italo F. Capasso B. AKA "Edwood Grant",

Comments

  • In short:
    The "traffic calculator" results are not exact but approximate the values you should see in real life.

    And this is why:
    The properties PhotonPeer.BytesIn and PhotonPeer.BytesOut are absolute for the client side. They take into account anything that's inside a UDP package (complete UDP / TCP payload).

    The post by Christof is maybe a bit misleading. The "traffic calculator" is giving an estimation but is not exact and complete. It is missing some data that goes over the wire in the background like ACKs and Pings and it does not cover nested data (hash in a hash). The actual traffic depends also on how much is sent reliable or unreliable and on packet loss, etc.


    So, you are not doing anything wrong but the values you chose are not directly comparable.

    Calculating the number of bytes that are sent from the photon server each "game step" is vital for me.

    This could prove tricky, as you can't exactly predict how many commands get into one packet and how much loss you have to compensate. You should approximate and plan with some buffers.
    Also I want to know what its the best way to send data in the hashtables,
    I usually put the keys as bytes (usually from an enum in C#), adn then the data (int, floats, strings, arrays, etc)

    I am also puting hastables inside hashtables because i need for example some information concerning a player only, so i create a hashtable for it, put some values and add it up to the rest of the data to send,.... maybe that is a terrible idea?

    Well, as always with optimization, you should optimize whatever you use most. If you send data of one player only every few seconds, you don't have to optimize that. At the beginning, you should probably just make sure your clients are able to receive 10 updates/sec and that they "consume" them in less than 100ms. Sending the ~400bytes/s is not bad in itself.

    You can nest hashtables of course, depending on your needs. Each layer of hashtable add a few bytes overhead. The inner hash has a byte-key and the hash itself contains of a "type"-byte, length (short) and key-value pairs. So it's not a good idea for position updates but the in hashes the data is easier to use and that could save you some work for rarely updated data.

    It's probably best not to optimize too much from the beginning. If you don't waste a lot of traffic for "spam", you should be fine. If your project finally reaches a limit, you probably know a lot better what you use in which way and how you can shave off a few bytes. There's a lot more room than just optimizing the datatypes: You could use "delta" updates later on, aggregate events or filter them depending on interest.


    It's difficult to give good advice on a project that I don't know. I hope the general tips are a guideline anyways.
  • This was a very helpful and very good advice. Just what I needed,

    Thanks a lot for your time :)


    Italo F. Capasso B. AKA "Edwood Grant",