Take the 2-minute tour ×
Game Development Stack Exchange is a question and answer site for professional and independent game developers. It's 100% free, no registration required.

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?

share|improve this question
    
You may find the real bottleneck is just in making the request and waiting for the response, regardless of server speed or payload size. –  michael.bartnett Oct 18 '11 at 22:40
add comment

3 Answers

up vote 9 down vote accepted

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.

share|improve this answer
    
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. –  Jamornh Oct 19 '11 at 15:37
    
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? –  Roy T. Oct 19 '11 at 19:30
    
What's nagling? –  Tor Valamo Oct 19 '11 at 21:34
    
@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. –  Jonathan Dickinson Oct 20 '11 at 8:06
1  
@TorValamo Nagle's Algorithm. –  Jonathan Dickinson Oct 20 '11 at 8:07
show 1 more comment

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

share|improve this answer
    
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. –  Jamornh Oct 21 '11 at 22:11
    
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 –  Stowelly Oct 24 '11 at 8:28
add comment

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.

share|improve this answer
add comment

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.