Dans le cadre de mon travail sur WAMP, j’ai proposé à Tobias de commencer par une présentation générale de la stack techno sous forme de slide show.
L’idée est de mettre ça dans le header des sites de WAMP, crossbar.io et autobahn, afin que quand les gens arrivent dessus ils puissent rapidement voir de quoi on parle. Ou alors, si on est sur un forum, on peut linker vers les diapos pour donner un contexte.
Comme prévu, je fais une première version en français que je poste ici. Puis je vais récolter vos commentaires : qu’est-ce qu’on comprend pas, quelles informations manquent, qu’est-ce qui est flou, ambigüe, etc.
Ensuite je l’améliorerai lors de la traduction en anglais qui sera ensuite proposée à Tavendo.
Slide 14 les deux premiers points me semblent répétitifs
Par rapport aux exemples (slide 18 et 27), peut être ajouter un slide avant pour expliquer ce que l’exemple doit faire (ou éventuellement déplacé un des deux slides “résultat” pour le mettre avant le code)
Slides 33 et 34 les mêmes
J’ai vraiment eu du mal à comprendre le slide 25 (et même la je suis pas trop sur d’avoir bien compris)
Avec le code de la partie PUB/SUB on ne voit selon moi pas suffisamment la différence par rapport au RPC. Ajouter 1 ou 2 navigateurs dans les screenshots ferrait plus d’effets.
J’ai pas compris ce que vient foutre le point 2 dans le slide 35, c’est un point positif non ?
Dans l’ensemble ça me semble assez bon pour une première approche.
Voili Voilou
J’attendais ce SlideShow avec impatience !
Je trouve le titre inadapté, à mon avis il faut soit parler d’un “Stack” soit cité toutes les techno que tu présentes, et comme WAMP sans Autobahn.io et Crossbar.io n’a pas vraiment de sens (pour le moment) il faut plus parler de Stack.
Ensuite si j’ai bien compris, ça se représente comme un Framework/Librairie/Autre pour gérer proprement webRTC (entre autre) ?
Salut,
slide 22 c’est AMQP pas AMPQ.
Sinon je trouve la présentation intéressante même si je n’ai pas actuellement de projet qui pourraient en bénéficier.
Merci.
Bonjour,
Bonne présentation,
Peut être un layus sur les perf vers le slide 35 : puis-je utiliser tout ça dans une boite qui compte plusieurs centaines/milliers de clients ?
La question qui me vient à la fin de la présentation : Comment j’intègre ça avec mes app Django existantes ? même si la mention «incompatible avec WSGI» est un élément de réponse.
A+
Comme se place le chiffrement dans tout ça ? Je pense notamment à la communication client-client.
@tous : merci pour tous ces points. Je vais m’y coller demain.
@Fennek : il n’y aucun WebRTC là dedans. Que du Websocket. Tout passe par crossbar.io. Je vais lever cette ambiguité.
@Seb : techniquement n’importe quel projet Web ou tu utilise Ajax/AngularJS peut en bénéficier. Après, dans sa forme actuelle, ça peut être overkill.
@bob : sur un rasberry, crossbar soutient 5000 connexions simultanées si je me souviens bien. Donc c’est large. Faut que je retrouve la source pour l’intégrer dans le slide. On ne peut pas répondre à toutes les questions dans un slide généraliste, surtout avec une techo qui fonctionne dans autant de langages. Mais la réponse est qu’on travaille sur un bridge (pas clair visiblement dans le slide) pour permettre l’intégration avec tous services HTTP synchrones.
@Yamakaky : c’est du websocket, donc SSL s’ajoute comme avec HTTP. Une URL webscket s’écris ws://foo.bar/, mais comme tu vois l’instance de démo est sur wss://foo.bar, car elle est sécurisé avec un certifcat SSL que crossbar charge.
Je ne vois pas trop la différence entre le RPC et le SUB/PUB : que se passe-t’il si deux clients déclarent un
session.register("callMeMaybe", function...)et qu’un autre client appelle unsession.call("callMeMaybe", ["Blah"])? quelle est alors la valeur de retour ?chiffrement : ah d’accord. Je croyais qu’il y avait du vrai p2p à la webrtc. Si j’ai bien compris tout les flux réseaux passent par le routeur WAMP ?
@Fennek : ce projet n’a rien à voir avec WebRTC, mais on peut l’utiliser pour la partie mise en relation des peers (si j’ai bien compris).
@Yamakaky : oui. Le routeur route justement. Il oriente les messages selon le nom qu’on lui passe vers les personnes intéressées. Sans ça, on ne peut pas savoir qui est intéressé. Cela dit, on pourrait coder une surcouche à crossbar pour qu’il fasse du signaling webrtc, c’est une techo très adaptée pour ça. C’est juste pas le cas pour le moment.
@Seb : c’est ce que je craignais. WAMP est plus facile à expliquer à quelqu’un qui sait ce qu’est le PUB/SUB et le RPC. Il va falloir que je modifie les slides pour faire plus clair. Quand on fait deux registers, le dernier gagne il me semble. Si tu veux faire communiquer deux navitateur, tu feras un register sur un truc du type nom.uuid, pour éviter les collisions. Si tu fais communiquer une partie serveur, un système de permission évite que n’importe qui puisse s’enregistrer à la place de ton code. Encore une fois, impossible d’expliquer tout ça dans un slide d’intro. Mais je vais voir si je peux glisser une ou deux lignes sur le sujet.
Toujours dans la sécurité, est-ce qu’il serait possible pour un attaquant de dos le serveur de login puis de publier sa propre procédure de login ?
Hello. Si tu peux eventuellement nous rassurer sur la maniere dont cela s’integre a une appli existante, ce serait top, mais vu qu’il s’agit de rapidement voir de quoi on parle, je pense que l’objectif est atteint. Heum, je pense que t’as deux slides qui disent la meme chose 33 et 34. Chapeau.
En parcourant le slideshow j’ai eu l’impression de lire trigger happy dans son esprit de la mise en application, du coup la question subsidiaire est : peut ton se (re)lancer dans l’écriture d’un projet ? Ou il faut encore un peu patienter que tu es dégrossi / produit la doc ?
ps : pour la traduction anglaise pour Tavendo : foxmask ; page 25 ; ca se traduit pas :D
Slide 6 : « par la main pour pour montrer »
Slide 17 : Un exemple de routeur léger serait intéressant
Slide 23 : 2 espaces après « pour envoyer des messages » Grammar Nazi :-p
Slide 26 : ‘setting il manque un ‘ après
Slide 26 : ‘newValue’ pour newValue
Je ne sais pas si il serait utile de mettre plus en avant la différence entre les 2 exemples : register/call et subscribe/publish.
J’ai trouvé ça plutôt clair, mais comme j’ai lu tous vos articles avant sur wamp, c’est difficile de le voir comme une première intro.
@Tontof :
Moi je l’ai lu en tant que “première lecture” (en fait, j’avais parcouru les autres articles, sans comprendre tout en détail, mais surtout sans y voir l’intérêt).
Là c’est en effet bien plus clair je trouve, et j’y ai trouvé un grand intérêt ^^
J’ai déjà pleins d’idées ^^
Merci à Sam et Max
Merci à tous pour vos remarques. Je vais faire une nouvelle version demain qui les prend en compte car il y a beaucoup plus de failles que je pensais. Particulièrement la différence entre RPC et PUB/SUB à l’air d’être encore floue, il faut que je travaille ça.
@lemeteore : pas dans les slides. La réponse est trop longue, elle dépend de la techno utilisée, de l’objectif, etc. Mais je ferai des tutos dans le futur pour ça.
@Yamakaky : le serveur de login, c’est toi qui le code. WAMP gère juste le RPC et le PUB/SUB, ce que tu en fais derrière, comment tu gère le throttling des requêtes, c’est la tâche du dev. Néanmoins, comme c’est de l’asynchrone non bloquant, ça tient bien mieux la charge qu’une autre techno. Après, tu pourras pas remplacer une fonction de login depuis l’extérieur car si tu fais un service d’authentification, tu ne donneras pas les permissions de créations de callback aux autres client pour ce service : un système de realm est intégré pour cela.
@foxmask : d’abord, je vais m’investir dans cette doc, car je pense qu’il y a beaucoup à gagner. Et derrière il y a ceci (avec cet objectif) qui risque de m’occuper du temps donc je vois pas où je pourrais caler un projet en plus. Tu peux nous rejoindre dessus si tu veux, mais c’est hautement expérimental, donc je ne communique pas dessus, car ça peut s’arrêter demain.
5000 sur un raspberry c’est bien .
Le slide 35 est explicite sur le fait que ça ne fonctionne pas encore, en relisant ma question sur comment intégrer ça avec django je me rend compte que c’est hors sujet c’est juste que suite à la lecture du slide j’ai trouvé une application pratique et que comme chez moi c’est Django c’est sorti tout seul.
Par ailleurs dans ce slide il manque le point d’interrogation au titre.
Je vais pas faire de remarque sur le contenu, je viens ici juste pour le fun et peut être un jour python ^^ (merci pour le message de service).
En revanche, si c’est pour une présentation, tu peux juste essayer d’harmoniser les couleurs, ça passe mieux auprès d’un auditoire.
Tu peux essayer http://www.colorschemer.com/online.html
Par exemple le slide 25, tu mets ton hexa rose FF00CC, tu récupère un bleu et avec “lighten scheme” tu as la couleur des carrés (idem pour les fleches, la bordure du rond rose, et même choisir le BON gris le fond etc..) 2 couleurs 3 max ca suffit pour toute la préz et tu te retrouves avec des bô slides !
Pour récupérer les hexa tu as ce tool gratuit
http://www.colorschemer.com/colorpix_info.php
C+
Merci Coquille
C’est super d’avoir des nouvelles de WAMP, c’est une techno qui donne très envie.
Concernant les slides, j’ai commencé à lire, mais perso, j’ai décroché au bout de 20 slides. Il y a trop de texte.
Mais c’est peut-être aussi parce que je savais déjà de quoi on parlait.
Je me demande vraiment combien de personnes ne connaissant pas WAMP iraient jusqu’au bout. C’est une stat à prendre en compte.
Une vidéo serait peut être plus parlante plutôt que des schémas.
Je me rappelle avoir adoré la présentation de SailJS
C’était clair, rapide et ça parle aux développeurs. Et en même y’a ce petit côté fascinant de voir quelqu’un d’autre travailler.
Mon égo vient de prendre un coup avec le lien html cassé… Je voulais parler de SailJS
yop. ça m’a l’air pas mal.
Le nom va être vraiment une merde sans nom pour la visibilité.. Et comme dirait mon père, il n’ai jamais trop tard pour bien faire. Dans le slide il me manque une notion de sécurité, j’ai l’impression que si je met l’url d’un serveur wamp dans ma page js, c’est open bar, tout le monde peux publier sont code, ou même bidouiller le code js existant.. j’avais déjà intégré nodejs dans un projet et c’était ce coté là qui m’a bloqué, comme le code est publique, c’est super chiant à sécuriser.
Merci beaucoup pour cette introduction !
Comme plusieurs autres au-dessus, je ne comprends pas tout à fait la différence entre RPC et Pub/Sub. En effet, pour appeler une procédure distante, je pourrais le faire via Pub/Sub comme cela :
B s’abonne à “call”
A s’abonne à “response”
A publie “call”
B reçoit le message et s’exécute
B publie “response”
A reçoit le message
Merci !
@Krypted: +1 mais une vidéo c’est beaucoup, beaucoup plus de boulot. Et plus compliqué à traduire.
@golgotha: meteor est chiant à sécuriser, mais nodejs, c’est de la technoweb ordinnaire, c’est exactement comme du Django. T’es pas sensé mettre ton auth côté client :) Mais ouai, je vais rajouter un slide sur la sécurité.
@Vayel: RPC : uniquement vers un client, et retourne une valeur. PUB/SUB, vers zero, une, ou plusieurs clients (on ne sait pas), et pas de valeur de retour. Je vais rajouter une slide pour ça.
Mais, justement, ne peut-on pas faire du RPC via PubSub avec la procédure décrite dans mon précédent message ? Certes c’est plus compliqué et RPC facilite la vie, mais ne sert-il qu’à ça ? Autrement, RPC apporte-t-il des trucs en plus de PubSub ?
Ouai mais tu doubles le code à écrire et la charge du routeur qui doit chercher deux fois a qui envoyer le message.
Tu pourrais aussi faire du pub/sub en faisant des boucles avec des id preconnus à l’avance. C’est pas efficace, c’est tout.
Tu peux aussi faire du PUB/SUB et du RPC avec du AJAX en faisant des pings réguliers et une machinerie manuelle côté serveur Web.
Tu peux aussi faire du HTTP en parsant les harders à la main car c’est du texte :)
Hello, juste une petite erreur sur la slide 28 sauf erreur, tu as mis le commentaire “appel de la fonction CallMeMaybe() sur l’autre nav” mais ça n’a plus lieu d’être
Merci Sam pour tes explications !
J’ai lu en page 35 qu’il n’y avait pas de server WSGI qui permette l’asynchrone mais ici http://asyncio.org/ on y trouve gunicorn (via aiohttp). Me gourge ?
Petite déconvenue, il me semble, un pip install crossbar m’impose twisted ; manque de bol je suis dans un pvenv 3.4 .
Donc si on veut utiliser le routeur on est bon pour rester en python 2 ?
Contrairement aux clients qui peuvent être codé avec twisted ou asyncio, le routeur est lié à twisted et donc à 2.7. Mais :
Pour ce qui est des workers WSGI asynchrone, c’est plus subtile que ça. Le serveur peut recevoir les requêtes asynchrones lui même (crossbar le fait d’ailleurs, il possède un conteneur wsgi), mais l’app WSGI ne permet aucune API asynchrone.
ah oui te me l’avais déjà dit pour crossbar j’avais oublié.
Ok j’ai pige pour l’app WSGI.
Donc si par exemple j’ai une appli django, il faut qu’elle se contente de traiter les données gérées par l’appli web, et les traitements asynchrones seraient gérés par crossbar&autobahn de façon completement “à part”
Merci pour le degrossisage (si, si !) Sam !
My 2 cents : peut-être que le problème de fond, c’est que beaucoup de gens n’ont même pas les bases pour comprendre tout ça ?
Exemple : je suis un dev Python qui fait un peu de Django par-ci, de dev Back par là, un peu de REST pour faire communiquer des services de temps en temps. Je suis loin, techniquement, de la frénésie du moment sur Websocket, PUB/SUB et RPC.
Je débarque et vois les slides, c’est un peu difficile de passer les premières étapes de compréhension pour voir ce que je peux gagner à m’intéresser à ça :
3 : Websockets ?
4 : Problème de nom ? Maladroit ? Pourquoi (pas très clair pour celui qui n’a pas bien saisi la slide #1)
5 : Heureusement qu’il y a l’exemple 1 (et éventuellement 2), car sinon ça peut faire peur : AMQP, ZeroMQ, MQTT
7 : RPC, PUB/SUB
Et seulement quand on arrive à la slide #8 on commence à avoir la vulgarisation :/ C’est un peu tard à mon avis. Il manque une “punchline” dans les premières slides, un truc qui donne envie de comprendre, de creuser, de lire les termes bizares qu’on ne comprend pas.
Car ensuite, les exemples qui viennent à partir de la slide #9 sont top : on comprend vite le principe (et l’intérêt si on a un besoin de ce type).
En tout cas, curieux de voir la suite, je sens que tout ça peut m’intéresser fortement !
Hum, c’est pas con. Faudrait peut être que je commence avec des exemples plus tôt.
Coucou,
Je suis depuis quelques temps votre blog et c’est super enrichissant. Un grand merci. Je me demande comment vous trouvez ce temps pour nous informer.
Petite question à propos de la techno :
Comment se comporte la reprise sur erreur ?
Si A n’arrive pas a envoyé un message à B comment est-t’il prévenu. Est-ce que le routeur retient tout cela ? Y a t’il des timeouts ?
Est-ce qu’il y peux y avoir des acks sur les messages (comme sur APMQ) (A est sûr que B a reçu son message)?
Est-ce qu’on a des utilitaires pour voir comment se comporte le router (management interface) ?
Tout dépend de l’implémentation. En Javascript, les promesses ont de callbacks d’erreur, en Python avec inlineCallback, c’est un simple try/except, etc.
Dans la spec oui, après je sais plus si crossbar l’implémente déjà ou pas. Je regarderai tout ça en détail au fur et à mesure que j’écrirais de la doc dessus.
Il n’y a pas d’outil graphique, pour le moment le seul outil pour regarder dans les entrailles du routeur est manhole, qui te permet d’ouvrir un debugger directement dans un routeur en fonctionnement et explorer ses divers threads.
C’est un super projet à coder d’ailleurs, un admin, mais je pense qu’il faudrait le faire sous forme d’un client qui écoute tous les events. Et pour faire ça, il faudrait que le routing avancé (avec wildcard) soit implémenté, ce qui n’est pas, il semble, encore le cas. Mais je pense que les dernières embauches de Tavendo sont justement là pour ça.
Autant au niveau des clients la fiabilié est laissé à l’imagination du développeur, mais est ce que quelque chose est prévu pour la disponibilité du serveur ? (qualifié de central dans ta prez, ça sonne très SPOF!)
Est ce que ça peut être un système répartie ?
(Si oui, comment ?)
Comme pour HTTP, avec un load balancer en front. Nginx permet de loadbalancer des websocket, donc on peut le faire se répartir sur plusieurs serveurs, qui ont chacun une copie de l’installation. Comme d’hab quoi.
Après, pour arriver à des milliers de personnes en simultané sur ton app, faut vraiment avoir du succès. Pour te donner une idée, le plus gros site de Max tient 300 000 vu / jours, avec temps moyen passé de 4 minutes sur le site. 300 000 / 34 * 60 / 4 = 833. On y est même pas.
Bien entendu, il y a des pics. Mais bon 300 000 visiteurs par jour quoi…
Néanmoins, les gars de tavendo visent de grosses installations, et ont donc comme projet de permettre de faire des clusters de crossbar qui répartiront la charge automatiquement. Et vu les embauches, je pense que ça va voir le jour.
@Sam : 4 minutes en moyenne ? Les gens savent plus prendre le temps… : ]
Techno qui à l’air intéressante, mais quel différence avec quelque chose comme : https://github.com/tj/axon sous nodejs
64 byte messages:
min: 47,169 ops/s
mean: 465,127 ops/s
median: 500,000 ops/s
total: 2,325,636 ops in 5s
through: 28.39 mb/s
ça fait la même chose, non ?
Merci pour l’article.
Même principe, mais :
RPC et PUB/SUB ne sont pas nouveaux. Il existe plusieurs serveurs HTTP, et il existent plusieurs techos pour faire du PUB/SUB et RPC.