Quel est le moyen le plus léger pour transmettre des données sur Internet en utilisant Python?

Question

J'ai deux ordinateurs répartis géographiquement, tous deux connectés à Internet. Sur chaque ordinateur, j'exécute un programme Python, et j'aimerais envoyer et recevoir des données de l'un à l'autre. Je voudrais utiliser l'approche la plus simple possible, tout en restant un peu sécurisé.

J'ai examiné les solutions suivantes, mais je ne suis pas sûr qui est le plus simple:

• serveur HTTP et le client, en utilisant protobuf *;
• Service web SOAP et client (pywebsvcs peut-être?);
• Une sorte d'IPC sur un tunnel SSH - encore une fois, protobuf peut-être?

Comme je l'ai dit, j'aimerais que la solution soit quelque peu sécurisée, mais la simplicité est la condition la plus importante. Les données sont très simples. objet de type A, qui contient une liste d'objets de type B, et d'autres champs.

* J'ai utilisé protobuf dans le passé, donc la seule difficulté serait de mettre en place le serveur HTTP, que je suppose être cherrypy.

Answer 1

Le moyen le moins coûteux et le plus simple de transmettre serait probablement XML-RPC. Il fonctionne sur HTTP (donc vous pouvez le sécuriser de cette façon), il est dans la bibliothèque standard, et contrairement à protobuf, vous n'avez pas à vous soucier de créer et compiler vos fichiers de type de données (puisque les deux extrémités exécutent Python, le typage dynamique ne devrait pas être un problème). Le seul inconvénient est que tous les types non représentés dans XML-RPC doivent être décapés ou sérialisés.

Answer 2

Ou vous pouvez aller directement à la bibliothèque Sockets et simplement transmettre les données dans votre propre format.

http://www.amk.ca/python/howto/sockets/

Answer 3

Vous pourriez envisager Pyro, assurez-vous de lire le Security chapter.

Mise à jour: Il semble plus simple à mettre en place que Buffers Protocole et peut exiger moins de travail si vos besoins deviennent plus complexes à l'avenir (ils ont une façon de le faire ... :-)

Answer 4

Protocole les tampons sont "légers" dans le sens où ils produisent une représentation très compacte du fil, économisant ainsi de la bande passante, de la mémoire, du stockage, etc. - tout en restant très polyvalent et multilingue. Nous les utilisons un lot chez Google, bien sûr, mais on ne sait pas si vous vous souciez de ces caractéristiques de performance - vous semblez utiliser "léger" dans un sens très différent de cela, strictement lié à la charge (mentale) sur vous, le programmeur, et pas tous avec charge (computationnelle) sur les ordinateurs et les réseaux ;-). Si vous ne voulez pas dépenser beaucoup plus de bande passante/mémoire/etc que vous ne le pourriez, et que vous ne vous préoccupez pas de la possibilité de coder les sous-systèmes participants dans différentes langues, les tampons de protocole peuvent ne pas vous convenir.

Si je lis correctement votre exigence de "peu de sécurité", je n'ai pas non plus besoin de pickling: le décompactage d'une chaîne pickled malveillante construite de manière appropriée peut exécuter du code arbitraire sur la machine de décomposition.En fait, HTTP n'est pas "un peu sécurisé" dans un sens légèrement différent: rien dans ce protocole n'empêche les intrus de "renifler" votre trafic (donc vous ne devriez jamais utiliser HTTP pour envoyer des données utiles confidentielles, sauf peut-être un cryptage fort). charge utile avant de l'envoyer et de l'annuler après l'avoir reçu). Pour la sécurité (encore une fois selon le sens que vous avez mis sur le mot), vous avez besoin de HTTPS ou (plus simple à configurer, ne vous oblige pas à acheter des certificats!) - Tunnels SSH.

Une fois que vous avez un tunnel SSH établi entre deux machines (pour Python, paramiko peut aider, mais même le faire via des scripts shell ou autrement en contrôlant directement le client en ligne de commande ssh n'est pas trop mauvais ;-) vous pouvez exécuter n'importe quel protocole dessus (HTTP est bien, par exemple), car les points de terminaison de tunnel sont rendus disponibles en tant que ports numérotés donnés sur lesquels vous pouvez ouvrir le socket. Je recommanderais personnellement JSON au lieu de XML pour coder les charges utiles - voir here pour un serveur et un client RPC JSON de type XMLRPC, par exemple - mais je suppose que l'utilisation du serveur XMLRPC et du client fourni avec la bibliothèque standard de Python est encore plus simple, donc probablement plus proche de ce que vous cherchez. Pourquoi voudriez-vous cherrypy en plus? Est-ce que la performance est soudainement en train de tromper la simplicité, pour cet aspect de l'architecture entière seulement, alors que dans tous les autres cas, la simplicité a été prise en compte pour la performance? Cela semblerait un ensemble de choix architecturaux particulièrement contradictoires! -)

Answer 5

Alex a raison, bien sûr. Mais, je vais dire que j'ai été très heureux dans le passé avec le décapage des données et le passage sur SSH à un autre processus de démêlage. C'est tellement facile.

Mais, il ne convient pas à beaucoup de choses. Vous avez vraiment besoin de faire confiance aux données entrantes, ce qui dans le cas de mon blog blog recevant un message de blog pickled (mon client analyse les balises ou autres), je fais confiance aux données - il est authentifié comme moi déjà.

Google, où Alex travaille, est un tout autre sujet. :-)