2010-06-04 6 views
1

Je suis en train de tester une application qui se connecte via un socket TCP asynchrone à un serveur C# et envoie 1 octet toutes les 30 secondes (implémentation d'un signal de présence). Après environ une heure plus tard, l'application avait envoyé 132 paquets (d'un octet) au serveur, les paquets ont été reçus ok. L'application iPhone est connectée une fois au serveur et ensuite les paquets sont envoyés via la connexion ouverte (le serveur n'envoie rien). Je l'ai fait pour mesurer la bande passante utilisée. Je suis donc allé à I Téléphone> Paramètres> Général> Utilisation et il a mesuré 366KB et 344KB vers le bas (j'avais réinitialisé les statistiques avant le test). Il n'y a pas d'autre application se connectant au réseau installé sur le téléphone et j'ai essayé cela environ 5 fois avec des résultats similaires.iPhone sdk socket - bande passante utilisée

Est-ce naturel? Je n'ai envoyé que 132 octets, mais la bande passante utilisée était d'environ 710 kilo-octets (comme 7.000 de plus). Y a-t-il autant de surcoût de bande passante du protocole TCP/IP? Je suppose que je vais avoir les pires résultats avec une implémentation Http polling, cause des entêtes http.

Répondre

1

Non, quelque chose d'autre utilise la bande passante telle que Safari ou Mail vérifiant des mises à jour ou quelque chose. Il ne peut pas prendre 3K par paquet de haut en bas.

+0

Eh bien, j'ai supprimé le compte Gmail que j'avais sur le téléphone. Pour autant que je sache, il n'y a rien d'autre. Et il y a un modèle d'environ 5 kb par paquet, donc si je laisse l'application fonctionner pendant environ 90 secondes (3 paquets de 1byte envoyés), l'appareil ajoute 18 ko à la bande passante utilisée ... – Plato

+0

encore une chose, sur le C# côté serveur, il y a nod32 en cours d'exécution, qui signale que le tcpListener (application serveur C#) a reçu un trafic entrant de 132 octets! Il semble donc que le côté serveur mesure la bande passante utilisée correctement, mais pas Iphone. Le problème est que si le fournisseur de services mobiles mesure en tant qu'appareil Iphone, le coût pour le client pourrait être important. – Plato

+0

Wow, c'est beaucoup de frais généraux pour 1 octet. Vous pouvez en savoir plus sur la surcharge de bande passante en établissant une ligne de base et plusieurs tailles de paquets différentes. (1) Exécutez votre application pendant 90 minutes, mesurez la bande passante, mais désactivez l'envoi de votre octet, cela vous donnera une utilisation de base des processus en arrière-plan, (2) même test que votre octet sauf 1k octets, (3) encore sauf envoyer 10k octets. – progrmr

0

Si vous utilisez une connexion wifi, il est possible de capturer tout le trafic vers et depuis l'iPhone en utilisant Wireshark sur un autre ordinateur. De cette façon, vous pourriez obtenir une indication sur quoi/où la bande passante supplémentaire est utilisée.

+0

J'utilise la connexion 3G du téléphone. Mais puisque j'ai accès à l'autre bout de la communication (le serveur) je vais essayer d'y capturer le trafic (ne vous attendez pas à trouver quoi que ce soit car au niveau du serveur le trafic entrant est correctement mesuré = nombre d'octets envoyer).Merci – Plato

+0

Si vous vous connectez au serveur via un schéma hostname.domain nommé, il peut s'agir de l'en-tête DNS que vous voyez. Si c'est le cas, essayez d'utiliser une adresse IP à la place et voyez si cela change quelque chose. –

+0

Non J'utilise l'IP pour les tests. J'ai utilisé comme application sniff du côté du serveur et le résultat était 50 octets de la taille totale du trafic pour chaque octet de données reçues par le serveur. C'est logique mais le 1 octet -> 5kb sur l'IPhone n'a tout simplement pas de sens. – Plato

0

J'ai également testé l'obtention de 1 octet (environ) du serveur via http (un asp.net httphandler qui répond avec le plain/text = 1). Je m'attendrais à ce que cette méthode utilise plus de bande passante en raison des en-têtes http. Mais après avoir testé le périphérique Iphone signale que chaque requête 1 octet du serveur (avec tous les en-têtes http) a coûté environ 3,5 Ko. Encore moins par rapport au coût moyen (5kb - 7kb) de chaque paquet lors de l'utilisation des prises directes TCP.

0

Il y a une surcharge pour chaque paquet qui est envoyé ou reçu et un surcoût supplémentaire pour configurer ou démonter la connexion. L'envoi de nombreux petits paquets entraînera beaucoup de surcharge TCP, et la seule mesure des octets reçus à l'autre extrémité du serveur ne comprendra pas le surcoût. Si vous voulez moins, passez à UDP et faites face aux complexités du maintien de la connexion vous-même.

En outre, il est probable que d'autres processus du système d'exploitation utilisent la bande passante en arrière-plan. Désactiver toutes les notifications mail/calendrier/push pour de meilleurs résultats.

Questions connexes