FAQ

Les pages web et les services web basés sur IMu utilisent l’API IMu pour communiquer avec imuserver. Cette communication se fait via des sockets TCP standard. Comme c’est habituellement le cas avec les logiciels client/serveur basés sur TCP, imuserver écoute les connexions sur des ports spécifiques et les programmes clients de l’API IMu se connectent au serveur sur ces ports.

Il est assez courant que les sites exécutent un imuserver et des clients basés sur IMu, tels que des pages web et des services web, sur des machines distinctes. Il est également fréquent qu’il y ait un pare-feu entre la machine client (généralement un serveur web) et la machine imuserver. Si tel est le cas, IMu ne fonctionnera pas à moins que les ouvertures appropriées ne soient ménagées dans le pare-feu. Cette FAQ décrit comment déterminer quelles ouvertures doivent être prévues dans le pare-feu.

Lorsque imuserver démarre, il écoute sur un port dédié. Le numéro de port est spécifié dans le fichier de configuration du serveur (généralement ~/etc/imuserver.conf) par le paramètre main-port. Par convention, ce port est 20000 de plus que le port utilisé par le client EMu. Par exemple, le port du client EMu d’artdemo est 20136, donc l’imuserver d’artdemo utilise 40136. (Notez que imuserver ne connaît pas réellement le port du client EMu pour un environnement. Vous devez donc définir au moins cette valeur ; si vous ne le faites pas, elle prendra la valeur par défaut 40000, de la même manière que le port du client EMu prend par défaut la valeur 20000.)

Une fois que imuserver a commencé à écouter sur le port principal, il peut créer plusieurs processus enfants pour aider à traiter les requêtes. Ceci est contrôlé par le paramètre process-count. Tous ces processus seront à l’écoute sur le même port et lorsqu’un programme de l’API IMu se connectera à un imuserver, n’importe lequel des processus pourra accepter la connexion.

Cela convient jusqu’à ce qu’un programme sans état, tel qu’une page web, veuille se connecter au même processus imuserver qui a traité sa requête initiale. Par exemple, une page Web peut lancer une recherche et récupérer le premier ensemble de résultats correspondants. Plus tard, une deuxième page de résultats peut être nécessaire. La page web ne peut pas se connecter sur le port principal d’origine car cette connexion peut être acceptée par l’un des autres processus imuserver, qui ne savent rien de la recherche originale.

Pour résoudre ce problème, chaque imuserver alloue son propre port de reconnexion. Ceci est décrit en détail dans la section « Maintien de l’état » de la documentation correspondante de l’API IMu.

Les numéros de port de reconnexion utilisés sont contrôlés par le paramètre reconnect-port dans le fichier de configuration. Lorsqu’un processus imuserver a besoin d’allouer un nouveau port de reconnexion, il commence à partir de la valeur spécifiée par le paramètre reconnect-port. Si ce port est déjà utilisé, il essaie le port suivant et ainsi de suite jusqu’à ce qu’il trouve un port inutilisé. Les programmes de l’API IMu utilisent ensuite le port de reconnexion du processus imuserver pour s’assurer qu’ils communiquent avec le bon processus imuserver.

Par défaut, les numéros de port de reconnexion commencent à 5000 au-dessus du paramètre de port principal. Par exemple, si le port principal est défini sur 40136, la valeur par défaut du port de reconnexion sera 45136 et les ports de reconnexion seront alloués à partir de 45136.

Qu’est-ce que cela signifie en termes d’ouvertures dans un pare-feu entre le serveur web d’un site et le serveur exécutant EMu ? La règle générale est qu’il faut prévoir process-count + 1 ouvertures dans le pare-feu : une pour le port principal et une pour le port de reconnexion propre à chaque processus imuserver. Déterminer quels sont ces numéros de port est mieux illustré par les exemples suivants :

  1. Le fichier de configuration a main-port défini sur 40032, aucun paramètre reconnect-port et process-count défini sur 3.

    Quatre ouvertures sont nécessaires dans le pare-feu :

    • 40032 - le port principal, utilisé par les trois processus serveur
    • 45032 - le port de reconnexion pour le premier processus à en demander un
    • 45033 - le port de reconnexion pour le deuxième processus
    • 45034 - le port de reconnexion pour le troisième processus
  2. Configuration similaire à celle ci-dessus, mais sans process-count défini. La valeur process-count sera par défaut 1.

    Deux ouvertures seront nécessaires dans le pare-feu :

    • 40032 - le port principal
    • 45032 - le port de reconnexion

    Ici, un seul processus serveur est en cours d’exécution et donc logiquement un port de reconnexion séparé n’est pas strictement nécessaire. Cependant, l’implémentation actuelle d’imuserver nécessite l’allocation d’un port de reconnexion et sa disponibilité dans ce cas. Cela pourrait changer dans les futures versions d’imuserver.

  3. Un service informatique met en place la configuration nécessaire pour permettre à IMu de fonctionner entre un serveur web et le serveur EMu. Il y a un pare-feu entre les deux machines et le service informatique souhaite prévoir le plus petit ensemble contigu possible de ports à ouvrir dans le pare-feu, à partir du port 33000.

    Décidez d’abord du nombre de processus imuserver requis. Supposons que ce soit 5. Six ouvertures seront nécessaires de 33000 à 33005.

    Créez les paramètres de configuration suivants :

     process-count = 5 main-port = 33000 reconnect-port = 33001

Un dernier point mérite d’être souligné. Les numéros de port de reconnexion spécifiques dans ces exemples supposent qu’il n’y a pas d’autres programmes (qu’il s’agisse d’autres imuservers exécutés dans des environnements différents ou de programmes complètement différents) utilisant des numéros de port dans cette plage.

Supposons, par exemple, que dans le dernier exemple, un programme indépendant utilise le port 33002. Ce port ne serait pas disponible pour les processus imuserver à utiliser comme port de reconnexion. Cela ne poserait pas de problème pour les processus imuserver eux-mêmes ; lorsqu’un processus essaierait d’allouer son port de reconnexion, il utiliserait simplement le port disponible suivant en ignorant les ports indisponibles. Cela signifie que cinq processus serveur utiliseraient l’un des ports 33001 et 33003-33006. N’importe quel programme d’API IMu gérerait cela très bien et se reconnecterait simplement au bon processus imuserver sur le port que le processus imuserver lui indiquerait. Le seul problème surviendrait avec le pare-feu. Dans ce cas, les ouvertures créées ne seraient pas suffisantes, car l’un des processus imuserver finirait par écouter les reconnexions sur le port 33006. Le programme d’API qui tenterait de se connecter sur ce port échouerait, car il serait bloqué par le pare-feu. Un site web configuré de cette manière présenterait ce qui semblerait être des erreurs intermittentes. Cela pourrait être assez difficile à diagnostiquer.

La morale de l’histoire est que lorsqu’un pare-feu est impliqué, essayez toujours de vous assurer que la plage de ports de reconnexion ne chevauche pas les ports utilisés par d’autres programmes (ou d’autres imuservers).

Les pages web et les services web basés sur IMu utilisent l’API IMu pour communiquer avec imuserver. L’imuserver fonctionne dans un environnement client EMu. Chaque imuserver utilise à son tour un ou plusieurs processus texserver pour obtenir des informations des modules EMu. Chaque processus texserver utilisé par imuserver occupera un emplacement de licence Texpress.

Cependant, déterminer exactement combien d’emplacements de licence seront utilisés par IMu est en fait plus difficile qu’il n’y paraît à première vue. Il y a deux parties à la réponse.

Lorsque imuserver est démarré (généralement par emuload), il lit son fichier de configuration (qui se trouve généralement dans ~/etc/imuserver.conf). Le fichier de configuration comprend deux paramètres qui affectent le nombre de licences Texpress utilisées par imuserver :

  • server-pool

    Ce paramètre définit le nombre de texservers que l’imuserver doit démarrer pour l’aider à traiter les demandes. Ce nombre contrôle directement le nombre d’emplacements de licence utilisés.

  • process-count

    Ce paramètre définit le nombre d’imuservers qui doivent être lancés pour écouter les requêtes. Cela n’affecte pas directement le nombre de licences Texpress utilisées. Toutefois, si le fichier de configuration n’inclut pas de paramètre server-pool, la valeur par défaut de server-pool correspond à celle spécifiée pour process-count. Cette situation est assez courante car les versions antérieures d’imuserver ne créaient pas de pools de serveurs : chaque processus imuserver (parent et enfants) démarrait un texserver dédié pour traiter ses requêtes.

Il est important de noter qu’une fois que imuserver a pris un emplacement de licence en démarrant un texserver dans le cadre du pool de serveurs, cet emplacement de licence n’est pas libéré tant que l’imuserver n’est pas arrêté. C’est-à-dire que l’emplacement de licence n’est pas disponible pour une utilisation par le client EMu, même si l’imuserver est inactif.

Plutôt que d’utiliser le niveau d’accès par défaut, un programme de l’API IMu peut également envoyer une demande de connexion afin d’obtenir un accès en tant qu’utilisateur spécifique. Ceci est courant pour les applications basées sur IMu qui effectuent la capture de données. Lorsqu’un imuserver reçoit une demande de connexion, il démarre un texserver dédié pour :

  • Vérifier le nom d’utilisateur et le mot de passe
  • Fournir un accès approprié à l’information (en utilisant la sécurité standard au niveau des enregistrements).

Comme un nouveau texserver est lancé, chaque demande de connexion utilise un autre emplacement de licence Texpress.

Les emplacements de licence supplémentaires utilisés par une demande de connexion restent occupés jusqu’à ce que :

  • Le programme API envoie une demande de déconnexion.
  • La connexion reste inactive pendant un certain temps et expire. La durée avant expiration de la connexion est définie dans le fichier de configuration par le paramètre context-timeout.

Dans les deux cas, le texserver dédié démarré en réponse à la demande de connexion est arrêté et, par conséquent, l’emplacement de licence est libéré.

  1. Le fichier imuserver.conf comporte un paramètre server-pool défini sur 3 et un paramètre process-count défini sur 5.

    Lorsque imuserver démarre, il démarre d’abord un pool de 3 texservers. Une fois ces serveurs démarrés, l’imuserver crée 4 processus enfants. Cela signifie qu’il y a 5 processus imuserver au total (le parent et les quatre enfants) qui attendent tous des connexions provenant de clients basés sur l’API IMu (généralement des pages web ou des services web). N’importe lequel de ces cinq processus peut utiliser n’importe lequel des trois texservers pour obtenir des données d’EMu.

    Nombre d’emplacements de licence utilisés : 3.

  2. Un paramètre process-count de 2 et aucun réglage pour server-pool.

    Le paramètre server-pool est défini par défaut sur 2 (identique à process-count). L’imuserver démarre deux texservers et crée ensuite un seul processus enfant.

    Nombre d’emplacements de licence utilisés : 2.

  3. Aucun paramètre process-count et un paramètre server-pool de 4.

    Lorsqu’un paramètre process-count n’est pas défini dans la configuration, sa valeur par défaut est 1.

    Cette configuration, où le nombre de texservers est supérieur au nombre de processus imuserver, peut sembler un peu étrange car d’habitude un seul imuserver ne traite qu’une seule requête à la fois. Toutefois, certaines requêtes peuvent être exécutées de manière asynchrone. Dans ce cas, il peut être judicieux d’avoir plusieurs texservers disponibles pour aider à traiter les requêtes.

    Nombre d’emplacements de licence utilisés : 4.

  4. Un paramètre process-count de 2 et aucun paramètre server-pool. Un programme API soumet une requête login pour s’authentifier et accéder aux données EMu en tant qu’utilisateur enregistré.

    Nombre d’emplacements de licence utilisés : 2 pour fournir un accès par défaut, 1 supplémentaire pour fournir un accès authentifié. Ce troisième emplacement est utilisé à partir du moment de la requête login jusqu’à ce que le même programme soumette une requête logout ou que la connexion expire.