5
\$\begingroup\$

I'm currently working on an iOS turn-based client-server game and I am concerned over later performance issues.

How much data per message is too big? I am planning to use JSON to transfer data (and, if possible, gzip it for more compression) and try to send as little as possible to make it work, but is there a figure I should keep in mind so that I do not exceed and is there a best-practice way of compressing this data?

On a side note, will this prevent me or affect whether I will use secure connections like SSL?

Improve this question
\$\endgroup\$
2
  • \$\begingroup\$ You may find the real bottleneck is just in making the request and waiting for the response, regardless of server speed or payload size. \$\endgroup\$
    – michael.bartnett
    Oct 18, 2011 at 22:40
  • \$\begingroup\$ This is well-known pitfall known as premature optimization. You don't show that you performed any tests, so you're trying to optimize under the false pretense that you're going to get a performance gain; yet you haven't measured the performance to begin with. At the very least, you're wasting your own time. At worst, you're going to introduce application-breaking bugs. Focus on building your program first, then optimize performance bottlenecks. \$\endgroup\$
    – arkon
    Aug 9, 2015 at 9:14

3 Answers 3

Reset to default
11
\$\begingroup\$

You will probably need to micro-manage the 3G modem to ensure that you don't have delays while it switches power modes. Your simple answer is make sure you send at least one packet larger than 128 bytes every 6-8 seconds. If you can guarantee that all your packets are smaller than 128 bytes make sure you send something once every 6-8 seconds. Avoid, at all costs, switching between 3G power states in a game as you will be cut off for 2.5 seconds while the transition occurs.

My Packets Are All Smaller Than 128 Bytes

Have a timer kick off every 6 seconds or so. If no packet has been sent since the last timer event, send a small heartbeat packet (4 bytes is probably safe).

If you sometimes need to send large data you could queue it up for temporary jumps to DCH.

Turn OFF Nagling if you are using TCP.

My Packets Could be Larger Than 128 Bytes

Have a timer kick off every 6 seconds or so. If no packet has been sent since the last timer event, that is at least 128 bytes; send a large heartbeat packet (196 bytes is probably safe).

Turn ON Nagling - if acceptable (i.e. your game is not real-time).

2.5s Delay is Acceptable

This is probably your case.

Do nothing special. Just make sure that your UI is ready for something like this (i.e. ensure it supports background workers/async).

More Info

Taken from the rather good XMPP mobile recommendations. Keep in mind these are not set in stone, and are up to the network operator - you can get feedback about this from the phone on some platforms:

Idle

connections but no data, ~8mA

This mode is used when connections are not actively sending/receiving data.

FACH

<= 128 bytes per packet, ~140mA

This mode is used when the packet queue remains smaller than 128 bytes for 8s. It takes 2.5s for your cellphone to move from idle to FACH.

DCH

> 128 bytes per packet, ~380mA

This mode is used when one or more connections are sending packets larger than 128 bytes at least once every 8 seconds. It takes 2.5s for your cellphone to move from FACH to DCH.

Improve this answer
\$\endgroup\$
6
  • \$\begingroup\$ Thanks, this was really helpful. This will help me work out how I should split my data packets and how to keep the connection alive. In some parts I won't be able to tollerate a 2.5s delay so I know when to keep the connection from switching modes and when it does not matter and to expect a delay. \$\endgroup\$
    – Jamornh
    Oct 19, 2011 at 15:37
  • \$\begingroup\$ That's really great info. I didn't know switching power states was so slow for 3G phones. From Idle To Fach to DCH would take 5 seconds. Is this because it needs to negotiate a new type of connection? \$\endgroup\$
    – Roy T.
    Oct 19, 2011 at 19:30
  • \$\begingroup\$ What's nagling? \$\endgroup\$
    – Tor Valamo
    Oct 19, 2011 at 21:34
  • \$\begingroup\$ @RoyT. unfortunately I don't actually know - the problem is there is very little information on this subject; you might have to experiment. I would assume it would be able to jump from idle to DCH immediately. I'll get hold of the author of the XEP and see if he knows. \$\endgroup\$
    – Jonathan Dickinson
    Oct 20, 2011 at 8:06
  • 1
    \$\begingroup\$ @TorValamo Nagle's Algorithm. \$\endgroup\$
    – Jonathan Dickinson
    Oct 20, 2011 at 8:07
1
\$\begingroup\$

Basically, it depends. Don't worry about it until you have a bottle neck. However you probably won't hit any issues on a 3g connection for a turn based game.

Improve this answer
\$\endgroup\$
0
\$\begingroup\$

I would advise against sending it in json as it is in plain text. your computer reads and understands binary, your server reads and understands binary, so why not just put the data into the pakcets in this format. sending any other way has unnecessary overhead, compression / decompression and overhead in parsing, when you could just stream your objects into and out of the packets

Improve this answer
\$\endgroup\$
2
  • \$\begingroup\$ I've never sent data in binary before. I've only used HTTP so far for sending data over the internet so I was going with what I knew. I'll look into working with binary since you're saying that it is faster. \$\endgroup\$
    – Jamornh
    Oct 21, 2011 at 22:11
  • \$\begingroup\$ you can send binary packets via http, not too sure what language your developing in for me to be able to provide any examples, but try to look into data packing \$\endgroup\$
    – Stowelly
    Oct 24, 2011 at 8:28

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .