Key string size when sending SFSObjects

[maxisilva]

HI everybody! This is my first post and I've been using Smartfox 2.x for a game project for 2 months now, that aims at being very scalable, for a lot of users. I like it a lot so far, and I am learning as I go.

I would like to ask the experts here a recommendation about SFSObjects.
When sending SFSObjects between the server and the client, someone recommended me to send very short strings as keys (2 or 3 characters, not much readable), and map them to enums to avoid transferring too much data.

e.g: Inserting an object as "gI" instead of "game_id" as a key in the SFSObject

While this makes perfect sense to me, then I ask myselft: If that's a concern, why don't we have at least the option to use (ver small in size) integers as keys? Isn't sending strings quite innefficient?.

So I would like to ask:
- Is there any negligible difference between sending (8 character keys on average) or very short (2-3 characters)? Is this a valid optimization?
- Is there a better way to optimize the key size I'm not aware of?

Cheers!

[Lapo]

While this makes perfect sense to me, then I ask myselft: If that's a concern, why don't we have at least the option to use (ver small in size) integers as keys? Isn't sending strings quite innefficient?.

It is a matter of common sense. We recommend using small keys just to make sure people understand that keys carry some weight too.
If you're sending tens of positional messages per second where the key names are: "space_ship_x_coordinate", "space_ship_y_coordinate", "space_ship_z_coordinate" you could definitely save some bandwidth by using "x", "y", "z"... or similar

- Is there any negligible difference between sending (8 character keys on average) or very short (2-3 characters)? Is this a valid optimization?

Again, I'd use common sense
If a message gets sent 20 times/sec by each client I'd choose the shortest key available.
Same thing is an object contains dozens of keys.
Other than that it's not much of a concern plus packet compression will mitigate the problem anyways.

- Is there a better way to optimize the key size I'm not aware of?

No, just be aware that long, very descriptive key names are probably going to waste some resources.

Cheers

[maxisilva]

Thanks Lapo! This clarifies things. Sorry if it looked like kind of dumb, just confirming

Cheers

[TomPo]

Hi
Old post but.... how to check the size of the sfsobject ?

Not asking about sfsobject.Size() to check how many elements are inside but about the "weight" of the package we are going to send via NET.
IS there an built-in method to check the real size of the package after serialization/compression etc which will travel over the Internet ?

Just want to know for example how often I can send snapshots of the game (positions, rotations etc) via UDP if I know that I want to stay under 3 MB per match.

[Lapo]

Hi,
you can print the hex dump of the object, like this:

Code: Select all

sfsObj.getHexDump()

which will show something like this:

Code: Select all

Binary size: 27
12 00 01 00 08 47 72 65 65 74 69 6E 67 08 00 0B    .....Greeting...
48 65 6C 6C 6F 20 57 6F 72 6C 64                   Hello.World

In the example the size of 27 bytes refers to the non compressed data, however the server will compress data when it passes the "compression threshold" configured in the server. (default = 1024 bytes)
Compression can reduce message size by a factor of 2x to 10x, depending on the complexity and size of the packet.

Hope it helps

[TomPo]

Thanks for the answer and.... hmmm.. well....
Synchro function

Code: Select all

        ISFSObject ob = new SFSObject();
        ob.PutUtfString("A", "S"); //Action, Synchro
        ob.PutInt("N", nr); nr++; //number
        ISFSArray array = new SFSArray();
        foreach(Player p in PlayersManager.Inst.AllPlayers.Values) {
            array.AddSFSObject(p.GetObject());
            // array.AddSFSObject(p.GetObject()); // add second for testing
        }
        ob.PutSFSArray("a", array);
        Debug.Log(ob.GetHexDump());


GetObject

Code: Select all

        ISFSObject ob = new SFSObject();
        ob.PutShort("i", ID); //short
        ob.PutFloatArray("p", Helper.GetFloatArrayFromVector(this.transform.position)); //float[2]
        ob.PutFloat("r", this.transform.localEulerAngles.y); //float
        return ob;


So what we have:
ob (string, string + stirng, int) -> array of objects (string, short + string, float[2] + string, float) //put 1 ob into array for testing
2 + 5 -> 1 + (3 + 9 + 5) = 25 bytes pure data and Binary Size: 55

Two things:
- looks like sfs object is quite heavy itself - 30 bytes difference between pure data and the size of sfs object.
- after add additional 17 bytes obj (3+9+5) into array make the whole obj at size: Binary Size: 86 (31 bytes more !) - interesting :/
After add third ob into array: Binary Size: 117 - so looks like every 17 bytes object added to array makes it 31 bytes bigger :/

14 objects (number of players in match) make the sfs object with the size of 458 bytes :/
And this is only for package like: package identifier, package nr, for each player: player id, player pos and player rot - doesn't look good.

458 bytes per synchro x 10 synchro per second (when like CS game have over 20) x 60 seconds x 15 minutes match = 8MB of data just for synchro :/
Am I missing something here ?!

[Lapo]

It really depends on what's your use case.
SFSObject/SFSArrays are high level data structures that work like Maps/Arrays. You can optimize the key values by making them 1 char short in SFSObjects but there will always be a minimum necessary overhead to describe the data structure in binary form.

If you need to trim every single possible bit then I'd recommend to create your own binary update format, serialize your updates in whatever byte format suits your needs, then wrap the byte[] in an SFSObject and send it.

Cheers

[TomPo]

Hi
As you can see above already using one char keys.
So yes, looks like using some BinaryFormatter serialization and send just one byteArray is the way.
Will see how it works in terms of size.