Envoi de données binaires via http
Je recherche des suggestions sur le meilleur moyen d’envoyer/recevoir des données d’un appareil GPRS distant, via le port 80.
La création d'un socket TCP ordinaire sur un port aléatoire fonctionne bien, mais de nombreux opérateurs n'autorisent le trafic HTTP du port 80 que par l'intermédiaire de leurs proxys, puis s'attendent à recevoir des données HTTP ascii (pour lesquelles ils peuvent modifier les en-têtes si nécessaire.
Mon appareil doit-il donc créer une demande POST sur une connexion HTTP persistante, puis recevoir une réponse codée en base64 du service Web? Je ne suis pas sûr de savoir comment les mandataires mobiles se comportent lorsque des données binaires sont impliquées. Y a-t-il une manière recommandée de faire ceci?
Je peux adapter le micrologiciel de l'appareil et l'application côté serveur.
[Modifier]
Je voudrais savoir s’il existe un moyen standard (plus ou moins) de le faire. Pour divers systèmes d’enregistrement de données et industriels, il est nécessaire d’envoyer de nombreuses données binaires via des connexions socket. Pour les connexions Ethernet, il n’ya généralement que des problèmes d’adaptation de certains pare-feu, mais les connexions binaires persistantes n’ont aucun mal à s’établir sur des ports arbitraires.
Les FAI mobiles, cependant, ont tendance à limiter leurs "plans de données" pour le port 80 uniquement. Ils prennent également la liberté de manipuler les en-têtes HTTP et potentiellement les données HTML elles-mêmes. C'est là que je dois identifier les pièges potentiels et les moyens de les contourner.
- L'envoi de données encodées en base64 fonctionnera-t-il?
- Comment sont gérées les sessions HTTP? Les sockets arbitraires peuvent rester en vie longtemps, mais les verbes HTTP ont généralement une courte durée de vie. Est-ce que cela signifie que je devrai créer une nouvelle connexion pour chaque paquet de données? Ou y a-t-il un moyen d'envoyer les réponses du serveur par gros morceaux, sur une seule connexion?
- De quelle manière un proxy ISP peut-il interférer avec les données ou les en-têtes? Par exemple, un proxy peut parfois maintenir une connexion active, même si le serveur la ferme.
L'envoi de données encodées en base64 fonctionnera-t-il?
Il n’est pas nécessaire d’utiliser le codage en base 64 - cela augmentera simplement le nombre d’octets que vous devez transférer. Les opérateurs de téléphonie mobile limitent généralement la modification des réponses aux types de contenu qu’ils comprennent, à savoir les images, les feuilles de style, etc.
Comment sont gérées les sessions HTTP?
Les sessions HTTP sont normalement gérées via un paramètre de requête URL ou via une valeur de cookie. Cependant, d'après ce que vous avez dit, cela ne semble pas être nécessaire.
Les sockets arbitraires peuvent rester en vie longtemps, mais les verbes HTTP ont généralement une courte durée de vie. Est-ce que cela signifie que je devrai créer une nouvelle connexion pour chaque paquet de données?
Les requêtes HTTP peuvent durer de manière arbitraire, comme pour les sockets raw TCP. Une demande GET peut durer des heures si nécessaire. Vous n'avez pas besoin de créer une nouvelle connexion pour chaque demande. Consultez l'en-tête HTTP Connection: Keep-Alive.
Ou y a-t-il un moyen d'envoyer les réponses du serveur par gros morceaux, sur une seule connexion?
Si vous ne connaissez pas la longueur de la réponse, vous pouvez omettre un en-tête Content-Length ou utiliser de préférence l'en-tête HTTP Transfer-Encoding: chunked.
De quelle manière un proxy ISP peut-il interférer avec les données ou les en-têtes? Par exemple, un proxy peut parfois maintenir une connexion active, même si le serveur la ferme.
Les FAI n'ont pas tendance à révéler les modifications qu'ils apportent aux réponses HTTP. Si cela vous inquiète, une solution simple consisterait à chiffrer les données et à spécifier un en-tête HTTP Content-Encoding. Cela nécessiterait de contrôler à la fois le client et le serveur HTTP.
Si possible, vous pouvez simplement envoyer les données sous forme de requêtes et de réponses HTTP.
HTTP est parfaitement capable de gérer des données binaires: les images sont envoyées via HTTP tout le temps et elles sont binaires. Les gens téléchargent et téléchargent des fichiers de types de données arbitraires tout le temps sans problème.
Donnez-lui simplement un type mime "application/octet-stream" - qui est fondamentalement un type mime générique pour les données binaires sans autre spécification de quel type - et les mandataires en cours de route devraient le laisser tranquille.
Implémentation ASP.NET C # du téléchargement de données binaires telles que des images sous la forme d'une demande POST vers l'URL cible :.
http://technowide.net/2012/09/01/upload-binary-data-http-post/