Lors du Django Meetup Paris numéro 2 (qui a eu lieu dans les locaux de 20 minutes, merci à eux pour le prêt de la salle (et à Julien pour l’orga) ), un petit récap des confs EuroDjango a été fait par Samuel (le frère de David, et oui un Paccoud peut en cacher un autre!!). Apparemment un des sujets porteur des EuroDjango avait été le ‘web temps réel’ (ce que je déteste ce terme tiens … temps réel, ça a un sens.. ça ne veut pas juste dire un truc en mode connecté) et la mise en place de celui ci dans Django (et du fait que peut être notre framework adoré n’était pas super en avance sur ce sujet).
J’en ai profité pour donner mon avis sur la question. A savoir qu’à mon sens, les serveurs webs n’était pas fait du tout pour gérer des connexions en mode connecté. Parce qu’ils n’ont pas été prévu pour cela. Idem pour le cœur de django qui n’est pas fait pour garder des pools de sockets, des états par connexion clientes, etc etc …
Alors qu’à contrario il y a des frameworks (je pense à twistted mais pas seulement) ou des manières d’écrire des serveurs qui permettent de gérer proprement des communications en mode connectées.
Il me semblait donc logique de ‘sortir’ la partie websocket du cœur de Django pour qu’elle soit gérer par ‘autre chose’. Il me semble qu’à la fin de ma tirade explicative, quelqu’un m’a dit ‘ben ok, fait le’ (me demande même si ce n’est pas ce fourbe de n1k0)
Du coup, ben ayant eu un peu de temps, ces jours-ci, j’ai rapidement fait un proto merdique de test.
Le principe a été de prendre l’exemple de simple chat de Gevent-SocketIO et de le ‘transformer’ en une commande de management Django. La commande de management simulant un serveur de gestion des connexions socketIO des utilisateurs. Du coté django, on a une première vue qui demande de donner un nickname puis on se retrouve sur la fenêtre de chat (qui utilise socketIO) et on peut discuter avec les autres connectés. J’ai rajouté deux petits trucs, pour le plaisir, le fait d’avoir les 5 dernières lignes de discussion (ça se récupère par la partie WebSocket) et le nombre de user et lignes de discussions totales (s’affiche la première fois par la connexion HTTP classique, se met à jour par les WebSocket)
Il faut donc à un moment ou un autre, lier la partie DjangoWeb de la partie SocketIO. Comme ce n’est qu’un prototype pour m’amuser, je passe à la vue de chat une key généré aléatoirement, key que me renvoie le client JS à travers la websocket.
Bon, bien entendu, tout cela n’est qu’un prototype pour expliquer (avec du code) la manière dont je voyais les choses. Bien entendu bis, il faudrait ‘lier’ la partie Web classique et Websocket d’une meilleure façon, ne pas utiliser une commande de management brute de décoffrage, potentiellement élaguer pas mal gevent-socketio pour enlever tout ce dont on n’aurait pas besoin, etc etc …
Mais voilà, j’avais juste envie de faire un test, d’en parler ici et de vous demander votre avis sur la question:)
4 Responses to “Django, websocket et bidouillage.”
Sorry, the comment form is closed at this time.
À vrai dire, pour ma part je fait ça avec Tornado. j’ai un moyen de récupérer les sessions django via memcache (ou le backend db mais ça paralise le process vu que ça n’utilise pas le modèle asyncrone) et pour les requetes complexes que je veux exécuter en syncrone django (read write db) un service json limité aux urls dites internals dans les settings. Il est utilisé par le client web async de tornado. Après, je fait le longpolling à la main car j’attend nginx 1.4 pour passer aux websockets. tornado a une implémention correcte de socket.io (tornadio).
Pour avoir des objects requests comme en django, il suffit de faire un handler adéquat. J’utilise ça en prod pour faire de simples notifs temps réel. je recharge les dernières notifs au démérage de mon application. Après, j’ai longtemps chercher le serveur de message queue qui me satisfasse pour faire de la communication distribuée dans un sens et simple dans l’autre et sans me prendre la tête avant de conclure que des serveurs http étaient déjà à l’écoute et pouvaient parler entre eux sans celery ou 0mq.
Tiens, ça me donne des idées de nouveau test à faire … 🙂
Cet article devrait te plaire alors : http://lucumr.pocoo.org/2012/8/5/stateless-and-proud/ 🙂
Oui, je l’ai lu des que david l’a twitté et je suis très en phase avec son contenu 🙂