Présentation de ZeroMQ

Certains l’écrivent ZeroMQ, d’autres 0MQ. D’aucun diront que  c’est un système de messaging et voudront le comparer à RabbitMQ ou ActiveMQ, d’autres pensent que c’est une couche de transport, une librairie, une API, un Framework, etc. Pour mieux comprendre ce que c’est, il est préférable de dire ce que ZeroMQ permet de faire :

  • C’est une couche de transport intelligente qui permet de construire des systèmes de communications simples ou complexes sans trop d’efforts.
  •  C’est une librairie de socket qui se comporte comme un Framework concurrent et permet à l’utilisateur d’implémenter les patterns de communication de son choix.
  •  ZeroMQ permet de transporter des messages via TCP, IPC et Multicast
  • Il permet d’avoir les performances d’un langage de bas niveau avec la facilité d’implémentation d’un langage de haut niveau. Concevoir un system complexe à partir de la librairie de socket pur est plus fastidieux.


Avantages :

  • Simple d’utilisation
  • Vitesse de transfert très rapide.
  • Courbe d’apprentissage assez courte pour les concepts de base.
  • Implémentation simple et rapide (quelques lignes) de patterns prêts à l’emploi comme (Request/Reply, Publisher/Subscriber)
  • Open source et licence libre(pour ceux qui veulent modifier le code source)
  • Supporte plus d’une 30 de langages (C, C++, Java, .NET, Python, etc.)
  • Multi OS (Linux, Windows, OS X)
  • Pas de configuration à faire.
  • Permet d’implémenter des applications distribuées.

Inconvénients :

  • Petite communauté d’une trentaine de membres actifs
  • Peu de ressources sur Google à part celles produite par le site ZeroMQ
  • On peut être bloqué des jours durant faute de réponses à ses questions

Background

L’aventure ZeroMQ commence en 2007 chez iMatix comme un projet à faible temps de latence OpenAMQ avec comme partenaires (Cisco, Intel)

Performance

ZeroMQ est très rapide (500.000 messages de 30 octets par second). Délesté de la complexité que peuvent avoir la plupart des systèmes de messages, 0MQ utilise de façon efficace les transports tels que le Multicast ou le Y-suite IPC transport et fait un usage intelligent du groupage de messages (intelligent message batching). Comparé à l’implémentation pure des sockets où il faut continuellement envoyer des données au buffer, l’envoi des messages se fait de façon asynchrone. Libre à l’utilisateur de choisir le mode de sérialisation qu’il souhaite. (JSON, Protocol Buffers, BSON ou Thrift. ZeroMQ l’interprètera comme un blob.

Comment ça marche

Cet article n’étant pas un tutorial, voici néanmoins un bref aperçu des concepts fondamentaux.

Trois étapes sont nécessaires à l’implémentation :

  • Choisir le mode de transport.
  • Choisir le pattern de communication.
  • Etablir les connexions

Choix du mode de transport

  •  TCP (transport via TCP) le plus utilisé
  • INPROC (communication intra processus)
  • IPC (communication inter processus)
  • MULTICAST  (transport via PGM)

Choix du pattern de communication

L’envoi de messages via 0MQ doit respecter les patterns suivants :

Etablir les connexions

Il s’agit de dire comment les différents composants seront connectés entre eux. De répondre à la question qui se connecte à qui ? Un composant se lie (BIND) à un port tandis que l’autre composant se connecte (CONNECT) à ce port.

 Il est possible que les composants communiquent via un intermédiaire qui se charge de redistribuer les échanges. ZeroMQ fournit des « devices » sur lesquels les composants viennent se connecter. A chaque pattern son device

  • QUEUE pour le pattern REQUEST/REPLY
  • FORWARDER pour le pattern PUBLISHER/SUBSCRIBER
  • STREAMER pour le pattern UPSTREAM/DOWNSTREAM

Maintenant, portons une petite attention sur le pattern PUBLISHER/SUBSCRIBER et voyons combien il est simple de l’implémenter.

PUBLISHER / SUBCRIBER

Imaginer une station de radio qui diffuse des chansons et des auditeurs qui écoutent. Seuls les auditeurs qui ont leur poste allumé et connecté à la bonne fréquence pourront écouter les chansons diffusées. Tel est le fonctionnement du modèle publisher/subscriber. Cependant dans le modèle, il est possible de filtrer ce que l’on veut écouter. Par exemple le premier auditeur ne voudra écouter que les chansons de Bob Marley. Le second auditeur, celles de Jimi Hendrix, et le troisième toutes les chansons.

Supposons alors que la radio diffuse : les chansons suivantes

Jimy Hendrix (Purple Haze), Bob Marley (No woman no cry), Jimy Hendrix (Hey Joe), Beatles (Girl),

le code suivant permet d’implémenter notre modèle en quelques lignes.

Le publisher

string[] Songs = { « Bob Marley (No woman No cry) », « Jimy Hendrix (Purple Haze) »,  « The Beatles (Girl) », « Jimy Hendrix (Hey Joe) »};
using (Context context = new Context (1))
{
using (Socket publisher = context.Socket (SocketType.PUB))
{
publisher.Bind (« tcp://127.0.0.1:5555 »);
foreach (string song in Songs)
{
publisher.Send(song, Encoding.Unicode);
}
}
}

Le subscriber 1

using (Context context = new Context(1))
{
using (Socket subscriber = context.Socket(SocketType.SUB))
{
subscriber.Connect(« tcp://127.0.0.1:5555 »);
subscriber.Subscribe(« Bob »,Encoding.Unicode);
string song;
while (true)
{
song = subscriber.Recv(Encoding.Unicode);
Console.WriteLine(song);
}
}
}

Pour que le subscriber 2 ne reçoive que les chanson de Jimi Hendrix, il suffira d’écrire le même code que le subscriber 1 et remplacer la ligne suivante

subscriber.Subscribe(« Bob »,Encoding.Unicode);
par
subscriber.Subscribe(« Jimi »,Encoding.Unicode);

Pour que le subscriber 3 reçoive toutes les chansons, utiliser le même code que le subscriber 1 et remplacer la ligne

subscriber.Subscribe(« Bob »,Encoding.Unicode);
par
subscriber.Subscribe(«  »,Encoding.Unicode);

REMARQUES:

implémenter le même pattern en .NET nécessitera plusieurs centaines de lignes de codes.

Laisser un commentaire

Votre adresse de messagerie ne sera pas publiée. Les champs obligatoires sont indiqués avec *