Django / Comet (Push): le moindre de tous les maux?

Question

J'ai lu toutes les questions et les réponses que je peux trouver concernant Django et HTTP Pousser. Pourtant, aucun n'offre une façon claire, concise, début jusqu'à la fin de la solution sur la façon d'accomplir une base "hello world" de soi-disant "comète" de la fonctionnalité.

Première question (1): dans quelle mesure le problème est que le HTTP n'est tout simplement pas (du moins jusqu'à présent) fait pour cela? Sont toutes les solutions possibles essentiellement des hacks?

2) Quel est le meilleur actuellement disponible solution?

• Mis sur orbite?
• Certains autres Tordus à base de solution?
• Tornade?
• node.JS?
• XMPP w/ BOSH?

Une autre solution?

3) quel est l'nginx pousser module de jouer dans cette discussion?

4) Lequel de ces solutions nécessitent le remplacement de la typique mod_wsgi / nginx (ou apache) modèle de déploiement? Pourquoi ont-ils besoin? Est-ce qu'un avis favorable de transition dans tous les cas?

5) Quelle sont les avantages de l'utilisation d'une solution qui est déjà en Python?

Alex Gaynor présentation de PyCon 2010, à laquelle je viens de regarder sur blip.tv, est étonnant et instructif, mais pas très précis sur l'état actuel de l'adresse HTTP Pousser dans Django. Une chose qu'il a dit qui m'a donné une certaine confiance: mis en orbite fait un bon travail d'abstraction et de simulation de la notion de sockets réseau. Ainsi, lorsque les WebSockets en fait la terre, nous allons être dans un bon endroit pour une transition.

6) Comment les Websockets HTML5 diffèrent des solutions actuelles? Est Gaynor, l'évaluation de la facilité de transition mis en orbite précise?

Answer 1

Je voudrais prendre un coup d'oeil à evserver (http://code.google.com/p/evserver/) si vous avez besoin d'une comète.

Il soutient "[le] peu connu Asynchrone WSGI extension" et construire autour de libevent. Fonctionne comme un charme et prend en charge django. Le gestionnaire réel de code est un peu moche, mais elle s'adapte bien que c'est vraiment async io.

J'ai utilisé evserver et je suis actuellement en train de cyclone (tornade sur twisted) parce que j'ai besoin d'un peu plus de evserver offsers. J'ai besoin de vrai bidirectionnel io (pensez à douille.io (http://socket.io/)) et tout evserver pourrait le soutenir, je pensais que c'était plus facile de réimplémenter tornade socket.io dans le cyclone (j'ai opté pour le cyclone au lieu de tornade comme le cyclone, c'est bâtir sur tordue, ce qui permet de mieux transports qui ne sont pas mises en œuvre dans le tordu (j'.c. zeromq)) Socket.io prend en charge les websockets, la comète style d'interrogation, et, beaucoup plus intéressant avec, à base de mémoire flash websockets. Je pense que dans la plupart des situations pratiques, les websockets + flash websockets sont assez à l'appui de 99% (selon adobe flash pénétration est d'environ 99% (http://www.adobe.com/products/player_census/flashplayer/version_penetration.html)) des visiteurs de sites web (seules personnes à ne pas utiliser le flash besoin de secours à l'un de socket.io son (moins perfomant et des ressources monopolisant) sauvegarde des transports)

Être conscient que les websockets sont pas un transport http , ainsi, de mettre derrière basées sur http proxy (e.g haproxy en mode http) interrompt la connexion. Mieux les servir sur une autre ip ou le port de sorte que vous pouvez proxy en mode tcp (e.g haproxy en mode tcp).

Pour répondre à vos questions: (1) Si vous n'avez pas besoin d'un transport bidirectionnel longpolling de solutions basées sur une assez bonne (tout ce qu'ils font est de garder une connexion ouverte). Les choses ne se douteuses lorsque vous avez besoin de votre connexion statefull ou vous avez besoin pour être en mesure à la fois envoyer et recevoir des données. Dans ce dernier cas socket.io aide. Cependant les websockets sont fait pour ce scénario et avec le soutien de flash disponibles à la plupart des sites web de visiteurs (via socket.io ou autonome, cependant socket.io a l'avantage de sauvegarde des transports pour ces gens qui ne veulent pas installer flash)

(2) si vous avez besoin de pousser, evserver est votre meilleur pari. Il utilise le même javascript, côté client, comme mis en orbite. D'autre oeil à douille.io (ce qui a aussi besoin d'un serveur, la seule python disponible est une tornade.)

(3) C'est juste un autre serveur de mise en œuvre. Si j'ai bien lu c'est pousser. envoi de données à un client est fait en faisant http equest à partir de votre application sur le serveur nginx. (nginx se charge alors qu'ils atteignent le client). Si vous êtes inteersted, mongrel2 (http://mongrel2.org/home) il n'a pas seulement des gestionnaires pour longpolling mais aussi pour les websockets.(au lieu de faire des requête http à mongrel, cette fois, vous utilisez zeromq gestionnaires afin d'obtenir les données de votre serveur mongrel) (notez le développeur du manque d'enthousiasme pour les websockets et à base de mémoire flash websockets. Surtout en tenant compte du fait que le protocole websocket tend à évoluer, vous pourriez, à un moment donné, besoin de ré-encoder mongrel2 du websocket vous soutenir garder d'avoir du soutien pour les websockets)

(4) Toutes les solutions sauf evserver remplacer wsgi avec quelque chose d'autre. Bien que la plupart des serveurs ont aussi quelques wsgi soutien ontop de cet "autre chose". N'importe quelle solution vous choisissez de faire attention à ce que l'un cpu intensive ou autrement io demande de blocage n'est pas de bloquer le serveur. (vous avez besoin de plusieurs instances ou threads).

(5) ne sont Pas très significatifs. Toutes les solutions dépendent de certains des gestionnaires personnalisés pour pousser (et, le cas échéant, de recevoir) des données au client. Toutes les solutions que j'ai mentionné permettre à ces gestionnaires afin d'être écrit en python. Si vous souhaitez utiliser un tout autre cadre (node.js ensuite, vous avez à peser la facilité de node.js (il est supposé pour être facile, mais il est également plutôt expérimental, et j'ai trouvé très peu de bibliothèques pour être vraiment stable) à l'encontre de la commodité d'utilisation de votre base de code et les bibliothèques (par exemple, si votre application a besoin d'un blog, il ya beaucoup de django blogs que vous pourriez brancher, mais aucun pour node.js) Aussi ne pas regarder vous-même l'aveugle sur les statistiques de performances. sauf si vous prévoyez de pousser muet de données prédéfinis (ce que tous les indices de référence) pour le client, vous constaterez que le réel de traitement de données ajoute beaucoup plus de ressources que même le pire des async io mise en œuvre. (Mais vous voulez toujours utiliser un async io serveur en fonction de si vous prévoyez d'avoir simultanément un grand nombre de clients, le filetage n'est tout simplement pas destiné à conserver des milliers de connexions)

(6) les websockets offre une communication bidirectionnelle, le temps d'interrogation/comet seulement la pousse des données, mais n'accepte pas écrit. (Socket.io simule cette bidirectionnelle à l'aide de deux requêtes http, l'un à longpoll, l'un à envoyer des données. Il fait le suivi de leur interdépendance (session) id de la partie de ces deux demandes de chaîne de requête). flash les websockets sont similaire à la vraie websockets (la différence est que leur mise en œuvre est dans le fichier swf, pas votre navigateur). Aussi les websockets protocole ne pas suivre le protocole http; longpolling/comet choses n' (techniquement le websocket client envoie une demande de mise à niveau de serveur websocket, la mise à niveau du protocole n'est pas plus http)

Answer 2

Il ya un soutien pour les WebSockets avec django-websocket, mais malheureusement il y a des problèmes majeurs avec elle pour la faire fonctionner; voici une citation de la page:

Disclaimer (ce que vous devez savoir lors de l'utilisation de django-websocket)

BIG FAT AVERTISSEMENT - droit au moment de sa techniquement PAS possible en aucune façon à utiliser un websocket avec WSGI. C'est un problème connu, mais ne peut pas être contourné de manière propre en raison de certains choix de conception qui ont été faites alors que le WSGI stadard a été écrit. En ce moment les choses comme les Websockets etc. n'existait pas et n'était pas prévisible.

...

Mais pas seulement WSGI est le facteur limitant. Django lui-même a été conçu autour d'une simple demande de réponse scénario sans Websockets dans l'esprit. Cela signifie également que l'offre d'un standard conforme websocket mise en œuvre n'est pas possible en ce moment pour django. Cependant, il fonctionne en quelque sorte dans une si jolie façon. Donc, être conscient que les sockets tcp peut obtenir torturé lors de l'utilisation de django-websocket.

Donc pour le moment, WSGI: no go; Django: à peine de l'aller, même avec django-websockets; voir aussi le commentaire de l'auteur original de l'annonce:

Je ne peux pas dire que cela ressemble à une bonne idée. Vous êtes en train de faire à long terme des connexions d'une manière qui va nécessiter le filetage. django-websocket exige le filetage de l'installation, et ne fonctionnera pas si vous avez des procédés (parce que vous avez juste trop de processus), mais les threads ne pour un grand nombre de connexions en même temps, donc c'est juste une fausse sécurité. Vous avez besoin d'un asynchrones plate-forme pour une longue durée de vie des choses, et je le fais en faisant de mon application dans Django et ma comète et websocket en Node.js

Personnellement, si vous essayez d'utiliser les WebSockets (j'attends d'être à l'année prochaine), je voudrais essayer la combinaison de Tordu et de Cyclone en premier. Ils sont conçus pour faire face avec les WebSockets, et de l'échelle. Si vous écrivez votre code correctement pour supprimer les dépendances sur Django, vous devriez être en mesure d'utiliser beaucoup de votre code dans un Tordu. C'est un très net avantage de l'utilisation de Node.js ou d'une Comète ou d'un système dans une autre langue. Vous pouvez aussi faire un simple push

Enfin, vous pourriez tout aussi bien décider que c'est trop dur et utiliser un service externe pour fournir la poussée de soutien. Que devient alors une question de l'envoi d'un simple JSON demande à leurs serveurs au lieu de s'inquiéter sur la façon de faire la connexion et comment la simultanéité de travail et des choses comme ça. Bien sûr, vous aurez besoin de payer pour cela (même si actuellement, il peut être libre alors qu'en version Bêta, mais vous n'avez pas à vous soucier des détails de mise en œuvre; vous n'aurez pas toute la puissance des WebSockets de cette façon, cependant, il suffit d'appuyer sur le soutien.

Answer 3

Concernant la question n ° 2, on m'a récemment fait visiter les fonctionnalités internes d'une application Django qui utilise beaucoup Comet, et Orbited a été la solution choisie.