Hi everyone, currently I'm developing MMO card games like Asshole,Blackjack,Poker ... with SFS 1X.
And I've just converted my code from XML protocol to String/Raw protocol.
But I still I wonder about the efficiency of String/Raw protocol, compare with XML protocol.
For example:
Before, when send 13 cards to player, I used XML and the length of message was about 700 bytes. Now I use String/Raw, and it's just about 70 bytes.
Does this mean that it's ten times faster than ? or something else ?
I can not find a clear answer in documentation or on this forum for this question, so please help me.
Thank you so much!!!
The efficiency of String/Raw protocol
-
eddyfosman
- Posts: 6
- Joined: 18 Jul 2011, 07:20
The efficiency of String/Raw protocol
Last edited by eddyfosman on 28 Jul 2011, 02:02, edited 1 time in total.
Yes, something like that.
This is an example of what each will look like:
smartfox.sendXtMessage("ext", "Test1", ["Test","Test"], "str");
smartfox.sendXtMessage("ext", "Test2", ["Test","Test"], "xml");
This is an example of what each will look like:
smartfox.sendXtMessage("ext", "Test1", ["Test","Test"], "str");
Code: Select all
%xt%ext%Test1%1%Test%Test%Code: Select all
<msg t='xt'><body action='xtReq' r='1'><![CDATA[<dataObj><var n='name' t='s'>ext</var><var n='cmd' t='s'>Test2</var><obj t='a' o='param'><var n='1' t='s'>Test</var><var n='0' t='s'>Test</var></obj></dataObj>]]></body></msg>Smartfox's forum is my daily newspaper.
-
eddyfosman
- Posts: 6
- Joined: 18 Jul 2011, 07:20
Raw protocol is good thing for optimization, but in my opinion, you should not optimize until needed. Fetching data on client is less readable when using string protocol instead of xml. JSON is probably good compromise between string and XML format for turn based games. I really doubt that you need anything better than JSON for card games. String is more suitable for high traffic real time games. I was doing some tests, and if I remember correctly JSON is 2-3 times lesser than xml, and string is 2-3 times shorter than JSON.
First rule of optimization is that you should not optimize prematurely. First make your application, then profile it to find bottlenecks, and if there is one optimize it.
Also, when you find bottleneck it might not be enough just to switch protocol. Depending on your application you might need to compress data in clever way to achieve shorter messages. For example, you said that sending 13 cards as a string data took around 70 bytes. You can probably compress it to around 8 bytes easily using bit flags. You could just send long integer (8 bytes - 64 bits) where each bit position from 0-51 represent one card in a deck. 13 bits of those long integer would be set to 1, and others would be set to zero. That way client will know which cards were sent from server, and it would take around 10 times less bandwidth.
First rule of optimization is that you should not optimize prematurely. First make your application, then profile it to find bottlenecks, and if there is one optimize it.
Also, when you find bottleneck it might not be enough just to switch protocol. Depending on your application you might need to compress data in clever way to achieve shorter messages. For example, you said that sending 13 cards as a string data took around 70 bytes. You can probably compress it to around 8 bytes easily using bit flags. You could just send long integer (8 bytes - 64 bits) where each bit position from 0-51 represent one card in a deck. 13 bits of those long integer would be set to 1, and others would be set to zero. That way client will know which cards were sent from server, and it would take around 10 times less bandwidth.