views:

198

answers:

4

Hi, 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. 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.

Any ideas?

Thanks in andvance...

+1  A: 

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.

progrmr
Well I've deleted the Gmail account I had on the phone. As far as I know there is nothing else. And there is a pattern of about 5 kb per packet, so if I let the app work for about 90 sec (3* 1byte packets sent) the device adds 18 kb to the used bandwidth...
Plato
one more thing, on the C# server side, there is nod32 running, which reports that the tcpListener (C# server app) has received 132bytes inbound traffic! So seems like the server side measures the bandwidth used correctly but Iphone does not. The problem is, if the mobile provider measures as the Iphone device, the cost for the client could be significant.
Plato
Wow, that's a lot of overhead for 1 byte. You could find out more about the bandwidth overhead by establishing a baseline and several different packet sizes. (1) Run your app for 90 minutes, measuring bandwidth, but disable sending your 1 byte, this will give you a baseline usage of the background processes, (2) same test as your 1 byte except send 1k bytes, (3) same again except send 10k bytes.
progrmr
A: 

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.

Claus Broch
I'm using the phone's 3G connection. But since I have access to the other end of the communication(the server) I'll try to capture there the traffic (do not expect to find anything there since at the server level the inbound traffic is measured correctly= num of bytes I actually send). Thanks
Plato
If you are connecting to the server through a named hostname.domain scheme, then it might be the DNS overhead you are seeing. If that's the case then try switching to using an IP address instead and see if that changes anything.
Claus Broch
No I'm using the IP for the tests. I used as sniff app at the server side and the result was 50 bytes total size of traffic for each 1 byte of data received by the server. That's logical but the 1byte -> 5kb on the IPhone just doesn't make sense.
Plato
A: 

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.

Plato
A: 

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.

rpetrich