• axon ne marche pas dans le navigateur; WAMP fonctionne sur tout nav >= IE10 avec une simple lib.
• axon ne marche qu’avec nodejs. Il existe des clients WAMP en C, Python, PHP, Java, C#, etc. Mais aussi des serveurs dans d’autres langauges.
• axon n’a pas de fonctionalités de sécu comme des permissions; Donc si tu as ta socket ouverte, on peut overrider tes fonctions.
• un client doit obligatoirement se taper tout nodejs. Pas moyen de faire un client léger; Pas d’arduino, pas d’embed dans un app bureau sans un gros blog, ni les apps téléphones.
• le serveur ne contient aucun gestionnaire de process. Il faut s’en occuper à part.
• axon n’est pas un standard enregistré; WAMP a une spec (https://github.com/tavendo/WAMP/blob/master/spec/basic.md) et est officillement un standard enregistré auprès de l’iana (http://www.iana.org/assignments/websocket/websocket.xml)

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.

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.

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.

Est ce que ça peut être un système répartie ?

(Si oui, comment ?)

Comment se comporte la reprise sur erreur ?

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.

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)?

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.

Est-ce qu’on a des utilitaires pour voir comment se comporte le router (management interface) ?

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.

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) ?

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 !

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”