iPhone sdk socket - bandwidth used

I am testing an app that connects through an asynchronous TCP socket to an C# server and sends 1 byte every 30 sec (implementing a heartbeat). After about an hour later the app had sent 132 packets (of one byte) to the server, the packets have been received ok. The iPhone app connected once to the server and after that sent the packets through the open connection (the server sends nothing). I did that to measure the bandwidth used.开发者_Python百科 So I went to I Phone >Settings>General>Usage and it measured 366KB up and 344KB down (I had reset the statistics before the test). There is no other app connecting to the net installed on the phone and I've tried this about 5 times with similar results.

Is this natural? I only sent 132 bytes but the bandwidth used was about 710 Kilobytes (like 7.000 more). Is there that much bandwidth overhead from the TCP/IP protocol? I guess I'll have worst results with an Http polling implementation, cause of the http headers.

---

No, something else is using bandwidth such as Safari or Mail checking for updates or something. It can't be taking 3K per packet up and down.

---

If you are using wifi connection it is possible to capture all traffic to and from the iPhone by using Wireshark on another computer. This way you might get an indication to what/where the extra bandwidth is being used.

---

I also tested getting 1 byte(about) from the server through http (an asp.net httphandler that responds with the plain/text =1). I would expect that this method would use more bandwidth because of the http headers. But after testing the Iphone device reports that each 1byte request from the server (with all the http headers) costed about 3.5kb. Still less compared to the average cost (5kb - 7kb) of each packet when using direct tcp sockets.

---

There is overhead for each packet that is sent or received and additional overhead to setup or teardown the connect. Sending many small packets will incur a lot of TCP overhead, and only measuring the bytes that are received at the other end of the socked won't include the overhead. If you want less, switch to UDP and deal with the complexities of maintaining the connection yourself.

Additionally, it's likely there are additional OS processes using bandwidth in the background. Disable all mail/calendar/push notifications for best results.