RFC2810 page - 6 - Kalt

Groupe de travail Réseau

C. Kalt

Request for Comments : 2810

avril 2000

RFC mise à jour : 1459


Catégorie : Information

Traduction Claude Brière de L’Isle



Relais pour la causette Internet : architecture



Statut de ce mémoire

Le présent mémoire fournit des informations pour la communauté de l’Internet. Il ne spécifie aucune norme de l’Internet. La distribution du présent mémoire n’est soumise à aucune restriction.


Notice de copyright

Copyright (C) The Internet Society (2000). Tous droits réservés.


Résumé

Le protocole de relais pour la causette Internet (IRC, Internet Relay Chat) est à utiliser avec des conférences fondées sur le texte. Il a été développé depuis 1989 alors qu’il été à l’origine mis en œuvre comme moyen pour que des utilisateurs sur un BBS discutent entre eux


Documenté pour la première fois en mai 1993 par la [RFC1459], le protocole a continuellement évolué. Le présent document est une mise à jour qui décrit l’architecture du protocole IRC actuel et le rôle de ses différents composants. D’autres documents décrivent en détail le protocole utilisé entre les divers composants définis ici.


Table des matières

1. Introduction 1

2. Composants 2

2.1 Serveurs 2

2.2 Clients 2

3. Architecture 2

4. Services du protocole IRC 3

4.1 Localisateur de client 3

4.2 Relais de message 3

4.3 Hébergement et gestion de canal 3

5. Concepts d’IRC 3

5.1 Communication d’un a un 3

5.2 D’un à beaucoup 4

5.3 D’un à tous 4

6. Problèmes en cours 5

6.1 Adaptabilité 5

6.2 Fiabilité 5

6.3 Encombrement du réseau 5

6.4 Confidentialité 5

7. Considérations pour la sécurité 5

8. Prise en charge et disponibilité actuelle 5

9. Remerciements 6

10. Références 6

11. Adresse de l’auteur 6

12. Déclaration complète de droits de reproduction 6


1. Introduction

Le protocole de relais pour la causette Internet (IRC, Internet Relay Chat) a été conçu sur un certain nombre d’années pour être utilisé avec des conférences fondées sur le texte. Le présent document décrit son architecture actuelle.

Le protocole IRC se fonde sur le modèle client-serveur, et convient bien pour fonctionner de façon répartie sur de nombreuses machines. Un établissement normal implique un seul processeur (le serveur) formant un point central auquel se connecter pour les clients (ou d’autres serveurs), qui effectue la livraison/multiplexage et autres fonctions de message requises.


Ce modèle réparti, qui exige que chaque serveur ait une copie des informations d’état globales, est toujours le problème crucial du protocole car il a un handicap sérieux qui limite la taille maximum qu’un réseau peut atteindre. Si les réseaux existants ont été capables de continuer à croître à une vitesse incroyable, on doit en remercier les fabricants qui nous ont donné des systèmes toujours plus puissants.


Dans le présent document, les mots clés "DOIT", "NE DOIT PAS", "EXIGÉ", "DEVRAIT" NE DEVRAIT PAS", "RECOMMANDÉ", "PEUT", et "FACULTATIF" doivent être interprétés comme décrit dans le BCP 14, [RFC2119].


2. Composants


Les paragraphes qui suivent définissent les composants de base du protocole IRC.


2.1 Serveurs

Le serveur forme l’épine dorsale de l’IRC car il est le seul composant du protocole qui soit capable de lier ensemble tous les autres composants : il fournit un point auquel les clients peuvent se connecter pour parler les uns avec les autres [RFC2812], et un point pour que s’y connectent les autres serveurs [RFC2813]. Le serveur est aussi chargé de fournir les services de base définis par le protocole IRC.


2.2 Clients

Un client est tout ce qui se connecte à un serveur et qui n’est pas un autre serveur. Il y a deux types de clients qui servent chacun un objet différent.


2.2.1 Clients d’utilisateur

Les clients d’utilisateur sont généralement des programmes qui fournissent une interface fondée sur le texte qui est utilisée pour communiquer de façon interactive via IRC. Ce type particulier de client est souvent appelé un "utilisateur".


2.2.2 Clients de service

À la différence des utilisateurs, les clients de service ne sont destinés ni à une utilisation manuelle ni pour parler. Ils ont un accès plus limité aux fonctions de causette du protocole, tout en ayant facultativement accès à des données plus privées de la part des serveurs.


Les services sont normalement des automates utilisés pour fournir certaines formes de service (pas nécessairement en rapport avec IRC lui-même) aux utilisateurs. Un exemple est celui d’un service collectant des statistiques sur l’origine des usagers connectés au réseau IRC.


3. Architecture


Un réseau IRC est défini par un groupe de serveurs connectés les uns avec les autres. Un seul serveur forme le plus simple réseau IRC.


La seule configuration de réseau permise pour les serveurs IRC est celle d’une interconnexion arborescente où chaque serveur agit comme nœud central pour le reste du réseau qu’il voit.


1--\

A D---4

2--/ \ /

B----C

/ \

3 E


Serveurs : A, B, C, D, E ; Clients : 1, 2, 3, 4


Figure 1 : Exemple de petit réseau IRC


Le protocole IRC ne donne pas de moyen pour que deux clients communiquent directement. Toute communication entre des clients est relayée par le ou les serveurs.


4. Services du protocole IRC


Cette section décrit les services offerts par le protocole IRC. La combinaison de ces services permet la conférence en temps réel.


4.1 Localisateur de client

Pour être capable d’échanger des messages, deux clients doivent être capables de se localiser mutuellement.


Lors de sa connexion à un serveur, un client s’enregistre en utilisant une étiquette qui est ensuite utilisée par les autres serveurs et clients pour savoir où est situé le client. Les serveurs sont chargés de garder la trace de toutes les étiquettes utilisées.


4.2 Relais de message

Le protocole IRC ne donne pas de moyen de communication directe entre deux clients. Toute communication entre les clients est relayée par le ou les serveurs.


4.3 Hébergement et gestion de canal

Un canal est un groupe désigné d’un ou plusieurs utilisateurs qui vont tous recevoir les messages adressés à ce canal. Un canal se caractérise par son nom et ses membres actuels ; il a aussi un ensemble de propriétés qui peuvent être manipulées par (certains de) ses membres.


Les canaux fournissent le moyen d’envoyer un message à plusieurs clients. Les serveurs hébergent les canaux et fournissent le multiplexage de message nécessaire. Les serveurs sont aussi chargés de gérer les canaux en gardant trace de tous les membres du canal. Le rôle exact des serveurs est défini dans la [RFC2811] "Relais pour la causette Internet : gestion de canal".


5. Concepts d’IRC


Cette section est dédiée à la description des concepts réels qui sous-tendent l’organisation du protocole IRC et comment sont livrées les différentes classes de messages.


5.1 Communication d’un a un

La communication d’un à un est habituellement effectuée par les clients, car la plupart du trafic de serveur à serveur ne résulte pas de ce que des serveurs se parlent seulement entre eux. Pour donner aux clients le moyen de se parler, il est EXIGÉ que tous les serveurs soient capables d’envoyer un message dans exactement une direction le long de l’arborescence d’interconnexion afin d’atteindre tous les clients. Donc, le chemin d’un message en cours de livraison est le plus court chemin entre deux points quelconques de l’arborescence d’interconnexion.


Les exemples qui suivent se réfèrent tous à la Figure 1 ci-dessus.


Exemple 1 : Un message entre les clients 1 et 2 est seulement vu par le serveur A, qui l’envoie directement au client 2.


Exemple 2 : Un message entre les clients 1 et 3 est vu par les serveurs A et B, et le client 3. Aucun autre client ou serveur n’est admis à voir le message.


Exemple 3 : Un message entre les clients 2 et 4 est vu seulement par les serveurs A, B, C et D et le client 4.


5.2 D’un à beaucoup

Le but principal d’IRC est de fournir un forum qui permette des conférences faciles et efficaces (des conversations de un à plusieurs). L’IRC offre plusieurs moyens d’y arriver, chacun servant à un objet propre.


5.2.1 À un canal

Dans IRC, le canal joue un rôle équivalent à celui du groupe de diffusion groupée ; son existence est dynamique et la conversation réelle portée sur un canal DOIT seulement être envoyée aux serveurs qui prennent en charge des utilisateurs sur un certain canal. De plus, le message DEVRA n’être envoyé qu’à chaque liaison locale, car chaque serveur est chargé de ventiler le message d’origine pour s’assurer qu’il va atteindre tous les receveurs.


Les exemples suivants se réfèrent tous à la Figure 1.


Exemple 4 : Tous les canaux ont un seul client. Les messages au canal vont au serveur et ensuite nulle part ailleurs.


Exemple 5 : 2 clients dans un canal. Tous les messages traversent un chemin comme si ils étaient des messages privés entre les deux clients en dehors d’un canal.


Exemple 6 : Il y a les clients 1, 2 et 3 dans un canal. Tous les messages au canal sont envoyés à tous les clients et seulement aux serveurs qui doivent être traversés par le message si il était un message privé à un seul client. Si le client 1 envoie un message, il revient au client 2 et ensuite via le serveur B, au client 3.


5.2.2 À un gabarit d’hôte/serveur

Pour fournir un mécanisme permettant d’envoyer des messages à un large corps d’utilisateurs en relation, des messages de gabarit d’hôte et de serveur sont disponibles. Ces messages sont envoyés aux utilisateurs dont les informations d’hôte ou de serveur correspondent à celles du gabarit. Les messages ne sont envoyés qu’aux sites où sont des utilisateurs, de façon similaire à ce qui se fait pour les canaux.


5.2.3 À une liste

Le style le moins efficace pour une conversation de un à beaucoup est lorsque les clients parlent à une 'liste' de cibles (client, canal, gabarit). La façon dont cela s’effectue s’explique d’elle-même : le client donne une liste des destinations auxquelles le message est à livrer et le serveur la décompose et expédie une copie séparée du message à chacune des destinations.


Ceci n’est pas aussi efficace que d’utiliser un canal car la liste de destinations PEUT être décomposée et l’expédition effectuée sans vérifier pour s’assurer qu’il n’y a pas de duplications dans les envois sur chaque chemin.


5.3 D’un à tous

Le type de message de un à tous est mieux décrit comme une diffusion de message, envoyé à tous les clients ou tous les serveurs, ou aux deux. Sur un grand réseau d’utilisateurs et serveurs, un seul message peut résulter en l’envoi d’une grande quantité de trafic sur le réseau afin d’atteindre toutes les destinations désirées.


Pour certaines classes de messages, il n’y a pas d’autre option que de les diffuser à tous les serveurs de sorte que les informations d’état détenues par chaque serveur soient cohérentes entre les serveurs.


5.3.1 Client à client

Il n’y a pas de classe de messages qui, à partir d’un seul message, résulte en l’envoi du message à tous les autres clients.


5.3.2 Client à serveur

La plupart des commandes qui résultent en un changement des informations d’état (comme de la qualité de membre d’un canal, du mode du canal, du statut de l’utilisateur, etc.) DOIVENT être envoyées par défaut à tous les serveurs, et cette distribution NE DEVRA PAS être changée par le client.


5.3.3 Serveur à serveur

Bien que la plupart des messages entre serveurs soient distribués à tous les 'autres' serveurs, ceci n’est exigé que pour les message qui affectent un utilisateur, un canal ou un serveur. Comme ce sont les éléments de base qu’on trouve dans IRC, presque tous les messages générés à partir d’un serveur sont diffusés à tous les autres serveurs connectés.


6. Problèmes en cours

Un certain nombre de problèmes posés par ce protocole ont été identifiés ; la présente section ne traite que des problèmes relatifs à l’architecture du protocole.


6.1 Adaptabilité

Il est largement reconnu que ce protocole ne s’adapte pas suffisamment bien à une utilisation dans une grande arène. Le principal problème vient de l’exigence que tous les serveurs connaissent tous les autres serveurs, clients et canaux, et que les informations les concernant soient mises à jour aussitôt qu’elles changent.


6.2 Fiabilité

Comme la seule configuration de réseau permise pour les serveurs IRC est celle d’une arborescence d’interconnexion, chaque liaison entre deux serveurs est un point de défaillance évident et assez sérieux. Ce problème particulier est traité plus en détails dans la [RFC2813] "Relais pour la causette Internet : protocole de serveur".


6.3 Encombrement du réseau

Un autre problème en rapport avec les questions d’adaptabilité et de fiabilité, ainsi qu’avec l’architecture d’arborescence d’interconnexion, est que le protocole et l’architecture pour IRC sont extrêmement vulnérables à l’encombrement du réseau. Ce problème est endémique, et devrait être résolu pour la prochaine génération : si l’encombrement et le volume élevé de trafic causent la défaillance d’une liaison entre deux serveurs, non seulement cette défaillance génère plus de trafic réseau, mais la reconnexion (éventuellement ailleurs) des deux serveurs va aussi générer plus de trafic.


Pour tenter de minimiser l’impact de ces problèmes, il est vivement RECOMMANDÉ que les serveurs n’essayent pas trop vite de se reconnecter automatiquement, afin d’éviter d’aggraver la situation.


6.4 Confidentialité

En dehors de ne pas bien s’adapter, le fait que les serveurs aient besoin de connaître toutes les informations sur les autres entités, la question de la confidentialité est aussi en problème. C’est particulièrement vrai pour les canaux, car les informations qui s’y rapportent sont bien plus révélatrices que de savoir si un usager est en ligne ou non.


7. Considérations pour la sécurité


À part les questions de confidentialité mentionnées au paragraphe 6.4 (Confidentialité) la sécurité n’est pas estimée être pertinente pour le présent document.


8. Prise en charge et disponibilité actuelle


Listes de diffusion de discussion en rapport avec IRC :

Discussion générale : ircd-users@irc.org

Développement de protocole : ircd-dev@irc.org


Mises en œuvre de logiciels :

ftp://ftp.irc.org/irc/server

ftp://ftp.funet.fi/pub/unix/irc

ftp://coombs.anu.edu.au/pub/irc


Groupe de nouvelles : alt.irc


9. Remerciements


Certaines parties du présent document ont été copiées de la [RFC1459] qui a été la première à documenter formellement le protocole IRC. Il a aussi bénéficié de nombreuses séances de révision et de commentaires. En particulier, les personnes suivantes ont fourni des contributions significatives à ce document : Matthew Green, Michael Neumayer, Volker Paulsen, Kurt Roeckx, Vesa Ruokonen, Magnus Tjernstrom, Stefan Zehl.


10. Références


[RFC1459] J. Oikarinen et D. Reed, "Protocole Internet de relais de débats", mai 1993. (Expérimentale)


[RFC2119] S. Bradner, "Mots clés à utiliser dans les RFC pour indiquer les niveaux d'exigence", BCP 14, mars 1997.


[RFC2811] C. Kalt, "Relais pour la causette Internet : gestion de canal", avril 2000. (Information)


[RFC2812] C. Kalt, "Relais pour la causette Internet : protocole client", avril 2000. (Information)


[RFC2813] C. Kalt, "Relais pour la causette Internet : protocole serveur", avril 2000. (Information)


11. Adresse de l’auteur


Christophe Kalt

99 Teaneck Rd, Apt #117

Ridgefield Park, NJ 07660

USA

mél : kalt@stealth.net


12. Déclaration complète de droits de reproduction


Copyright (C) The Internet Society (2000). Tous droits réservés.


Ce document et ses traductions peuvent être copiés et diffusés, et les travaux dérivés qui commentent ou expliquent autrement ou aident à sa mise en œuvre peuvent être préparés, copiés, publiés et distribués, partiellement ou en totalité, sans restriction d'aucune sorte, à condition que l'avis de droits de reproduction ci-dessus et ce paragraphe soient inclus sur toutes ces copies et œuvres dérivées. Toutefois, ce document lui-même ne peut être modifié en aucune façon, par exemple en supprimant la notice de droits d'auteur ou les références à l'Internet Society ou d'autres organisations Internet, sauf si c'est nécessaire à l'élaboration des normes Internet, auquel cas les procédures pour les droits de reproduction définies dans les processus des normes pour l'Internet doivent être suivies, ou si nécessaire pour le traduire dans des langues autres que l'anglais.


Les permissions limitées accordées ci-dessus sont perpétuelles et ne seront pas révoquées par la Société Internet, ses successeurs ou ayants droit.


Ce document et les renseignements qu'il contient sont fournis "TELS QUELS" et l'INTERNET SOCIETY et l'INTERNET ENGINEERING TASK FORCE déclinent toute garantie, expresse ou implicite, y compris mais sans s'y limiter, toute garantie que l'utilisation de l'information ici présente n'enfreindra aucun droit ou aucune garantie implicite de commercialisation ou d'adaptation a un objet particulier.


Remerciement

Le financement de la fonction d'éditeur des RFC est actuellement assuré par la Internet Society.