Chat : Présentation et configuration

1Présentation

Le but de ce tutoriel est de créer un système de discussion en temps réel multi-utilisateurs. Les utilisateurs auront accès à une interface très simple, avec un petit formulaire pour saisir leur nom et leurs messages, et en-dessous la liste des messages envoyés et reçus.

1.1Technologies

Pour mener ce développement, nous allons utiliser deux technologies spécifiques (qui sont gérées nativement par Temma) : les SSE (Server-Sent Events, ou événements envoyés par le serveur), et les communication réseau ZeroMQ.

  • Les SSE sont utilisés pour envoyer des messages depuis le serveur vers les navigateurs connectés au chat.
  • Les connexions réseau ZeroMQ sont utilisées pour les communications entre les contrôleurs et un "broker de messages", dont le rôle est de transmettre les messages reçus à tous les contrôleurs qui envoient des SSE.

1.2Contrôleurs

En plus du contrôleur qui sert à afficher l'interface web, il y a deux contrôleurs qui gèrent les échanges de données entre le navigateur et le serveur :

  • Les navigateurs se connectent aux contrôleurs Event dès que la page web est chargée. Ces contrôleurs envoient des SSE à chaque fois qu'un message a été envoyé par un utilisateur. Il y a donc autant de contrôleurs Event qui s'exécutent que de navigateurs connectés au site.
  • Les contrôleurs Message sont appelés en AJAX par les navigateurs lorsqu'un message est envoyé par un utilisateur.

1.3Fonctionnement

Voici un schéma global du fonctionnement lorsqu'un message est envoyé au serveur :

  1. Le message (et le nom de l'utilisateur) est envoyé au serveur via une requête AJAX très classique.
  2. Le contrôleur Message qui reçoit le message ouvre une socket ZeroMQ de type PUSH vers le broker, pour le transmettre le message.
  3. Le broker, qui était en lecture bloquante sur sa socket PULL, reçoit le message. Il le renvoit sur sa tocket sortante de type PUB (publication).
  4. Tous les contrôleurs Event, qui sont connectés à la socket PUB du broker avec une socket SUB (subscription), reçoivent le message. Ils le renvoient par SSE aux navigateurs qui leur sont connectés.

2Fichier de configuration

Il y a donc quatre socket ZeroMQ différentes : les PULL et PUB sont utilisées par le broker, les PUSH sont utilisées par les contrôleurs Message et les SUB sont utilisées par les contrôleurs Event.

Dans le fichier de configuration etc/temma.php, nous allons déclarer une source de donnée différente pour chaque type de socket ZeroMQ. Même si toutes les sockets ne sont pas utilisées en même temps (le broker en utilise deux sur les quatre, les contrôleurs n'en utilise qu'une), ce n'est pas un problème car les connexions ne sont réellement ouvertes qu'au moment où elles sont utilisées pour la première fois.

Voici le contenu du fichier :

<?php

return [
    'application' => [
        'dataSources' => [
            'zmq_client_push': 'zmq://PUSH@127.0.0.1:5000',
            'zmq_broker_pull': 'zmq-bind://PULL@127.0.0.1:5000',
            'zmq_broker_pub':  'zmq-bind://PUB@127.0.0.1:6000',
            'zmq_client_sub':  'zmq://SUB@127.0.0.1:6000',
        ],
        'enableSessions' => false,
        'rootController' => 'Homepage',
    ],
];

Les sources de données sont :

  • zmq_client_push : Socket PUSH utilisée par le contrôleur Message pour envoyer au broker le message qu’il a reçu.
  • zmq_broker_pull : Socket PULL utilisée par le broker pour recevoir les messages envoyés par les contrôleurs Message.
  • zmq_broker_pub : Socket PUB utilisée par le broker pour redistribuer les messages reçus vers tous les contrôleurs Event.
  • zmq_broker_sub : Socket SUB utilisée par les contrôleurs Event pour recevoir les messages publiés par le broker.

À la ligne 11, les sessions sont désactivées, car nous n’en aurons pas besoin.
À la ligne 12, on définit que le contrôleur racine (celui qui répond pour l'URL "/") est l'objet Homepage.