I have been doing all kinds of tests for a push system as well (instead of using C2DM).
The Android side was done in some very quick-and-dirty B4A apps.
The server side was done in some very quick-and-dirty C# app.
These are the things I tested:
- polling: have an Android service hit a URL every 30 seconds. The server would reply with a HTML with just a single character (indicating whether or not there was anything to be pushed).
- pushing: the Android service would make a TCP connection to my server app and leave this connection open. The TCP server would also reply with a single character every 30 seconds.
- pushing: run a TCP server on the Android device. to push a message I would need to open a telnet and send a message. Note: this avoids the need to have a server in between but can cause trouble when the Android device has been NATted.
In case of both pushing scenario's it is vital to determine whether a connection was lost as soon as possible, so a reconnect can be attempted. No open TCP connection, no push messages (of course
I just did these tests to be able to determine how much extra of the battery was drained in each scenario. This was quite substantial.
Piggy-backing on the already open connection to google server (C2DM) is a lot better, but it in fact depends on a possibility to open a connection to the Google servers.
As far as I am concerned to be continued