Implémentation du serveur push avec le framework Twisted

Question

Je suis en train de développer une discussion de groupe en utilisant le framework python Twisted. La technique que j'utilise est longue interrogation avec Ajax. Je retourne SERVER_NOT_DONE_YET pour garder la connexion ouverte. Le code est non-bloquant et permet d'autres demandes. Combien est-ce évolutif?

Cependant, je veux aller de l'avant de ce streaming sur les connexions ouvertes. Je veux mettre en œuvre une poussée de serveur pur. Comment faire ? Dois-je aller en direction de XMPP? Si j'ouvre une socket sur le serveur pour chaque client unique, quel serveur web conviendrait le mieux au pont? Combien serait évolutif? Je veux qu'il soit aussi évolutif que le problème de C10K. Je voudrais coller à Twisted parce qu'il a beaucoup d'implémentations de protocole en étapes faciles. S'il te plait, oriente moi dans la bonne direction. Thanx

Answer 1

L'interrogation longue, mais n'est pas nécessairement votre meilleure option. Il commence à devenir vraiment méchant en termes d'intégration avec les pare-feu et les connexions internet floconneuses. Par exemple, au travail, un grand nombre de pare-feu de nos clients détruisent toute connexion HTTP qui n'est pas active pendant 10 à 20 secondes.

Nous avons résolu de nombreux problèmes en passant à WebSocket via SSL. WebSocket vous offre un canal full-duplex, parfait pour le serveur. En utilisant SSL, les pare-feu sont souvent moins agressifs dans la collecte des ordures et transparent proxies are often fooled by the TLS encryption. Vous aurez toujours besoin de gérer la déconnexion occasionnelle au niveau de l'application, même si vous utilisez WebSockets au lieu d'un interrogation longue, mais même cela peut être géré avec élégance grâce à un protocole de récupération décent, quel que soit le protocole de transport utilisé. Ceci étant dit, au lieu d'aller directement à WebSockets, nous avons décidé d'utiliser SockJS. La raison principale de ce choix était que SockJS peut utiliser WebSockets quand il est disponible (rfc6455, hixie-76, hybi-10), mais aussi revenir à xhr-streaming, xdr-streaming, etc, si le navigateur du client ne le supporte pas (ou si la connexion échoue). Quand je dis qu'il peut "se replier", je veux dire que le code que vous utilisez du côté client reste exactement le même, SockJS s'occupe du sale boulot.

Côté serveur, la même chose est vraie. Nous utilisons actuellement CycloneSockJS implementation pour Twisted (en production), mais nous sommes également au courant de la mise en œuvre DesertBus', que nous avons encore à vérifier. Il y a aussi d'autres choses que nous espérons vérifier, par exemple WAMP, et le Autobahn|Python qui l'accompagne. En ce qui concerne les performances, nous utilisons HAProxy pour la terminaison SSL et l'équilibrage de charge. HAProxy performance is pretty amazing, sur une multitude de niveaux.

Answer 2

Nous avons migré vers WebSockets maintenant. Cela fonctionne parfaitement bien !!