From dee8939277e0fb695fb23e0dcc98559cb9996d16 Mon Sep 17 00:00:00 2001 From: Tobias Markmann Date: Wed, 6 Oct 2010 00:09:10 +0200 Subject: [PATCH] Fix use of definition lists. --- xep-0286.xml | 18 ++++++++++++++++++ 1 file changed, 18 insertions(+) diff --git a/xep-0286.xml b/xep-0286.xml index 17658c5c..2a7f2618 100755 --- a/xep-0286.xml +++ b/xep-0286.xml @@ -113,27 +113,45 @@

As with anything, there are no hard and fast rules. If there were, they might look like these. First, for devices:

+
Transmit no data.
Transmitting costs significant power, and moreover raises the radio state. Not transmitting will allow it to maximize the time spent in the low-cost Idle state.
+ +
If you must transmit, then transmit only a small volume.
If there is only a small amount of data transmitted - less than 128 octets typically - the radio will only raise to FACH, which is significantly cheaper than DCH.
+ +
If you must transmit, then compress as hard as possible.
Since individual octets have an associate power - and often financial - cost, it's worth maximizing the compression algorithm, even if the volume of traffic will raise to DCH.
+ +
If you have transmit a lot, then do a lot
If the radio is raised to DCH anyway, then you may as well go fetch that avatar you were missing, since you're chewing through power anyway.
+ +
If you receive, then transmit
If your peer raises the radio state, you may as well use it.
+

And for servers, similar rules apply:

+
Send no data.
Sending data will cause the handset to be raised out of Idle. This immediately costs massively higher power.
+ +
If you must send, send tiny bits.
Sending small enough data maximizes the likelyhood that the devices radio will only be raised to FACH levels.
+ +
If you receive, then send anything you have.
Receiving data indicates that the radio is active - it'll stay active for some time, so sending data doesn't incur the overhead of raising the radio state, and won't increase power drain on the handset.
+ +
If you must send when not receiving, send plenty.
Sending data will raise the radio's state - unless you can tell this will only raise it to FACH, it's worth sending as much as possible.
+

Finally, protocol designers should aim to minimize any responses required from the handset, and ensure keepalive traffic, if any, fits inside FACH wherever possible.