Introduction au protocole WAMP

Des applications découplées communiquant en temps réel

a marqué ce sujet comme résolu.

Un truc qui m'a surpris, dans l'exemple de code Pub/Sub, c'est la différence entre 'com.example.sub' (ligne 16) et 'com.example.pub' (ligne 26). C'est assez inhabituel, et dans les exemples de code trouvés ici je n'ai pas vu cette particularité. Ni dans la spec d'ailleurs.

En fait, les deux n'ont aucun rapport : le composant ne s'abonne pas du tout au topic qu'il envoie. Autrement dit, pubsubCallback ne sera appelée que lorsqu'un autre composant enverra le message com.example.sub. Je vais préciser ça. :)

+0 -0

Pourquoi je n'ai pas vu ce topic avant ? En fait j'ai vu ce matin que tu as forke certains depots de crossbar.io sur GitHub. :D

le composant ne s'abonne pas du tout au topic qu'il envoie

En fait il existe option a la publication pour ne pas etre exclu. Du coup, si sur cette simple option il est possible de ne pas etre exclu de la publication, cela signifie que le publisher est aussi de facto subscriber. A verifier dans la RFC (qui vient d'etre mise a jour il y a quelques jours).

Autrement dit, l'appel RPC ne bloque pas l'appelant, lequel ne perd pas son temps à attendre que l'appelé accomplisse son travail. Heureusement me direz-vous : on n'imaginerait pas rester devant sa boîte aux lettres en attendant de recevoir un retour de son correspondant.

C'est a mon avis a moderer. Il arrive frequemment que l'appelant ait le besoin de synchronisation. Auquel cas, on veut que l'appelant attende la reponse. C'est possible sous crossbar.io + Twisted (je sais pas avec asyncio) via le decorateur @wait_for me semble-t-il.

+0 -0

En fait il existe option a la publication pour ne pas etre exclu.

C'est exact ; je parlais juste pour l'exemple.

Du coup, si sur cette simple option il est possible de ne pas etre exclu de la publication, cela signifie que le publisher est aussi de facto subscriber.

Je ne comprends pas ce que tu dis là. Un composant peut être notifié d'un message qu'il publie, mais ce n'est pas le comportement par défaut.

C'est a mon avis a moderer. Il arrive frequemment que l'appelant ait le besoin de synchronisation. Auquel cas, on veut que l'appelant attende la reponse.

Il n'est pas possible d'effectuer un appel bloquant. Ou alors j'ai mal compris tes propos.

Petite question : pensez-vous qu'il faille conserver les deux schémas suivants ? Ils répètent le cas de figure et le paragraphe plus théorique.

Merci.

+0 -0

Ce n'est pas le comportement par défaut mais le fait que un composant puisse s'inclure via un paramètre du message envoyé signifie qu'il est déjà inscrit à son propre topic et que c'est le routeur, selon la valeur de ce flag, qui choisi s'il renvoie un message ou non. Pour preuve, si tu utilises crossbar.io, tu ne verras pas de log au niveau du routeur disant qu'il y a souscription à l'usage de ce paramètre.

Pour les appels bloquants il existe au moins 2 méthodes (dont la dernière que j'ai jamais utilisé pour des raisons de dépendances). La première consiste à simplement arrêter la boucle principale tant que le résultat n'est pas disponible. La seconde est l'utilisation du décorateur @wait_for(timeout) fourni par Crochet (dont je ne connais pas l'implémentation).

Je garderais les schémas personnellement.

+0 -0

Bonjour à tous !

La beta du tutoriel a été mise à jour.

Merci pour vos relectures

  • Mise à jour des examples de codes, pour simuler une situation réelle
  • Précision sur le caractère asynchrone d'un appel RPC, suite à la remarque de Höd
+0 -0

Bonjour les agrumes !

La bêta tutoriel « Introduction au protocole WAMP » a été mise à jour et coule sa pulpe à l'adresse suivante :

Merci d'avance pour vos commentaires.

  • Corrections orthographiques mineures
  • La démo JSFiddle est en principe fonctionnelle
+0 -0
Ce sujet est verrouillé.