I. Introduction▲
Ce mémo fournit des informations pour la communauté Internet. Il ne spécifie en aucun cas un standard pour l'Internet. La distribution de ce mémo est limitée.
Copyright (C) The Internet Society (2000). Tous Droits Réservés.
Traduction : Copyright (C) Mathieu Lemoine pour Developpez.com (2006). Tous Droits Réservés.
Le protocole IRC a été conçu il y a plusieurs années pour la gestion de conférences textes. Ce document décrit son architecture actuelle.
Le protocole IRC est basé sur le modèle Client/Serveur et est organisé afin de fonctionner en mode réparti sur différentes machines. Une installation typique met en jeu un unique point d'accès (le serveur) auquel les clients (et les autres serveurs) se connectent. Ce point d'accès effectuant les opérations de livraison et d'acheminement demandées.
Le modèle distribué, requérant que chaque serveur possède une copie de l'état global, est toujours le plus sérieux handicap du protocole étant donné qu'il s'agit là d'un sérieux handicap limitant la taille maximale d'un réseau. Si les réseaux existants continuent à s'étendre à un point incroyable, c'est grâce aux évolutions matérielles qui permettent d'avoir des systèmes de plus en plus puissants.
II. Composants▲
Les paragraphes suivants définissent les composants de base du protocole IRC.
II-A. Les Serveurs▲
Les serveurs forment le fondement d'IRC, car ils sont le seul composant du protocole qui est apte à relier entre eux tous les autres composants. Il fournit un point d'accès auquel les clients peuvent se connecter afin de communiquer, et auquel les autres serveurs peuvent se connecter pour étendre la capacité du réseau. Il est également responsable pour la mise à disposition des services définis par le protocole IRC.
II-B. Les Clients▲
Un client est tout ce qui se connecte à un serveur et qui n'est pas soi-même un serveur. Il existe deux types de clients, chacun ayant un rôle différent.
II-B-1. Les clients utilisateurs▲
Les clients utilisateurs sont généralement des programmes fournissant une interface texte permettant de communiquer interactivement via IRC. Ce type particulier de clients est souvent nommé plus simplement utilisateur.
II-B-2. Les clients de service▲
Au contraire des clients utilisateurs, les clients de service ne sont pas destinés à être utilisés comme défini dans le protocole, ni pour communiquer. Ils ont un accès limité aux fonctions de discussions du protocole, et parfois, des accès plus larges aux données privées des utilisateurs fournies par les serveurs.
Les clients de service sont généralement des bots utilisés pour fournir un service supplémentaire (pas forcément relié à IRC). Un exemple pourrait être un service collectant des statistiques sur les origines des utilisateurs d'un réseau IRC.
III. Architecture▲
Un réseau IRC est défini par un groupe de serveurs connectés les uns aux autres. Un serveur unique forme le plus simple des réseaux IRC.
La seule configuration autorisée pour les serveurs IRC est un arbre où chaque serveur agit comme un nœud central vis-à -vis de sa partie visible du réseau.
1--\
A D---4
2--/ \ /
B----C
/ \
3 ELe protocole IRC ne fournit aucun sens à la connexion directe entre deux clients. Toutes les communications entre clients doivent se faire via l'intermédiaire d'un ou plusieurs serveurs.
IV. Les services du protocole IRC▲
Cette section décrit les différents services offerts par le protocole IRC. La combinaison de ces services permet de tenir des conférences en temps réel.
IV-A. Localisation des clients▲
Pour pouvoir échanger des messages, deux clients doivent être aptes à se localiser l'un l'autre.
Quand il se connecte à un serveur, un client s'enregistre en utilisant un label qui est alors utilisé par les autres serveurs et clients pour savoir où le client est situé. Les serveurs sont responsables de la gestion de tous les labels en cours d'utilisation.
IV-B. Transmission des messages▲
Le protocole IRC ne fournit aucun sens à la connexion directe entre deux clients. Toutes les communications entre clients doivent se faire via l'intermédiaire d'un ou plusieurs serveurs.
IV-C. Hébergement et gestion des chans▲
Un chan est un groupe nommé d'un ou de plusieurs utilisateurs qui vont tous recevoir les messages adressés au groupe. Un chan est caractérisé par son nom et les noms de ses utilisateurs actuels, il peut également avoir un ensemble de propriétés qui peuvent être manipulées par (certains de) ses membres.
Les chans fournissent un moyen d'envoyer un message à plusieurs clients. Les serveurs hébergent les chans, fournissent la diffusion des messages. Ils sont également responsables de la gestion des chans en conservant la liste des membres. Le rôle exact des serveurs est défini dans Internet Relay Chat: Channel Management [IRC-CHAN].
V. Les concepts du protocole▲
Cette section a pour but la description des concepts présents derrière l'organisation du protocole IRC et comment les différents types de messages sont livrés.
V-A. Communication Un-Ã -Un▲
La communication Un-à -Un est généralement faite par les clients du fait que la majorité du trafic entre serveurs n'est pas le résultat de la communication stricte d'un serveur à l'autre. Afin de fournir un moyen aux clients pour parler les uns aux autres, il est NÉCESSAIRE que tous les serveurs soient à même d'envoyer un message dans une et une seule direction le long de l'arbre de manière à atteindre le client. Le chemin parcouru doit être le plus court possible.
Les exemples suivants font référence à la Figure 1 ci-dessus.
Exemple 1Â : un message du client 1 au 2 est vu uniquement par le serveur A, qui l'envoie directement au client 2.
Exemple 2Â : un message du client 1 au 3 est vu par les serveurs A et B. Les autres serveurs et clients ne le voient pas.
Exemple 3Â : un message du client 2 au 4 est vu par les serveurs A, B, C et D uniquement.
V-B. Un-Ã -Plusieurs▲
Le but principal d'IRC est de fournir un forum permettant de faire des conférences (conversations Un-à -Plusieurs) facilement et fiablement. IRC offre plusieurs moyens de le faire, chacun ayant son domaine d'application.
V-B-1. À un chan▲
Dans IRC, le chan a un rôle équivalent à celui du groupe de multicasting, son existence est dynamique et les conversations sur un chan ne DOIVENT être vues QUE par des serveurs étant reliés à des utilisateurs présents sur le chan. De plus, le message ne DEVRAIT être envoyé qu'une seule fois pour chaque lien partant d'un serveur. Pour résumer, il s'agit d'un mécanisme de multicasting.
Les exemples suivants font référence à la Figure 1(1) ci-dessus.
Exemple 4 : Chan avec un seul utilisateur. Le message arrive au premier serveur et est immédiatement détruit.
Exemple 5 : Chan avec deux utilisateurs. Le message suit exactement le chemin qu'il aurait pris dans le cas d'une conversation privée entre les deux utilisateurs.
Exemple 6 : Clients 1, 2 et 3 sur un même chan. Le message ne traverse que les serveurs qui seraient traversés si l'émetteur envoyait une conversation privée à chacun des autres membres du chan.
V-B-2. À un masque▲
Il est également possible d'utiliser un masque d'hôte ou de serveur. Dans ce cas, les messages ne sont envoyés qu'aux utilisateurs validant le masque. Les messages sont acheminés de la même façon que pour les chans.
V-B-3. À une liste▲
La façon la moins efficace de diffuser un message à plusieurs personnes est dans le cas d'une simple liste de destinataires. Dans ce cas, le serveur découpe simplement la liste et traite chaque destinataire indépendamment des autres.
Ce n'est pas aussi efficace que la diffusion à un chan, car il est possible que la liste soit erronée (destinataire inexistant) ou que le message soit envoyé plusieurs fois sur le même lien.
V-C. Un-Ã -Tous▲
La communication Un-à -Tous se définit mieux comme la communication en broadcast. Un message est envoyé à tous les serveurs et/ou tous les clients. Sur un réseau de grande taille, un unique message peut entraîner un trafic extrêmement important du fait qu'il doit atteindre tout le monde dans le réseau.
Pour certains messages, c'est la seule possibilité envisageable du fait que chaque serveur doit posséder son état du réseau à jour.
V-C-1. Client à Client▲
Il n'existe pas dans le protocole IRC de message ni de communication permettant à un client d'envoyer un message à tous les autres clients.
V-C-2. Client à Serveur▲
La plupart des commandes – hors envoi de message – provoquent un envoi de ce type, du fait que les serveurs doivent maintenir leur état du réseau à jour.
V-C-3. Serveur à Serveur▲
La plupart des messages émis par un serveur vers un autre concernent l'état du réseau et donc doivent être transmis à tous les autres serveurs.
VI. Problèmes actuels▲
Il existe quelques problèmes reconnus avec ce protocole, cette section ne relate que les problèmes liés à l'architecture du protocole.
VI-A. Adaptabilité selon la dimension d'un réseau▲
Il est unanimement reconnu que ce protocole s'adapte très mal à des réseaux de très grande taille. Le problème principal vient du fait que chaque serveur doit connaître tous les autres, tous les clients connectés à chaque serveur, tous les chans… De plus, ces informations doivent être à jour en permanence.
VI-B. Robustesse vis-Ã -vis des serveurs▲
Du fait qu'un réseau IRC doit être en forme d'arbre, chaque connexion de serveur à serveur est un point de fiabilité très important. Ce problème est plus particulièrement débattu dans Internet Relay Chat: Server Protocol [IRC-SERVER].
VI-C. Congestion du réseau▲
Du fait des deux points précédents, le protocole IRC est extrêmement vulnérable aux congestions réseau. Ce problème est endémique : si une connexion entre deux serveurs tombe à cause de la congestion (ou parle alors de split), chaque serveur devra envoyer un message pour chaque serveur et chaque client avec lequel il a perdu contact. De plus, la réactivation de la connexion provoque généralement, encore plus de trafic.
Afin de minimiser l'impact sur le congestionnement du réseau, il est fortement RECOMMANDÉ de configurer les serveurs pour qu'ils ne se reconnectent pas automatiquement trop vite.
VI-D. Confidentialité▲
Du fait que chaque serveur doit connaître l'état du réseau, la confidentialité est quasi nulle sur le réseau. En particulier pour les chans, les informations qui y sont liées sont bien plus significatives que le simple fait qu'un utilisateur soit ou non connecté.
VII. Sécurité▲
Du fait du problème décrit, la sécurité n'est pas prise en charge par ce document.
VIII. Support actuel et disponibilité▲
Listes de diffusions pour les discussions sur IRCÂ :
En général : ircd-users@irc.org
sur le développement du protocole : ircd-dev@irc.org
Implémentations logicielles :
ftp://ftp.irc.org/irc/server
ftp://ftp.funet.fi/pub/unix/irc
ftp://coombs.anu.edu.au/pub/irc
Newsgroup :
alt.irc
Forum d'entraide(2)Â :
http://www.developpez.net/forums/forumdisplay.php?f=392
IX. Remerciements▲
Certaines parties de ce document ont été copiées de la RFC 1459 [RFC] qui est la première documentation formelle et officielle du protocole IRC. Elles ont également bénéficié de plusieurs passes de relectures et de commentaires. En particulier, les personnes suivantes ont fait d'importantes contributions à ce document :
Matthew Green, Michael Neumayer, Volker Paulsen, Kurt Roeckx, Vesa Ruokonen, Magnus Tjernstrom, Stefan Zehl.
X. Références▲
- [KEYWORDS] Bradner, S., « Key words for use in RFCs to Indicate Requirement Levels », BCP 14, RFC 2119, March 1997.
- [IRC] Oikarinen, J. and D. Reed, « Internet Relay Chat Protocol », RFC 1459, May 1993.
- [IRC-CLIENT] Kalt, C., « Internet Relay Chat: Client Protocol », RFC 2812, April 2000.
- [IRC-SERVER] Kalt, C., « Internet Relay Chat: Server Protocol », RFC 2813, April 2000.
- [IRC-CHAN] Kalt, C., « Internet Relay Chat: Channel Management », RFC 2811, April 2000.
XI. Adresse de l'auteur▲
Christophe Kalt 99 Teaneck Rd, Apt #117 Ridgefield Park, NJ 07660 USA
EMail: kalt@stealth.net
XII. Droits d'auteurs▲
Copyright (C) The Internet Society (2000). Tous Droits Réservés.
Ce document et ses traductions peuvent être copiées et transmises à d'autres, des travaux annexes le commentant ou l'expliquant ou aidant à son implémentation peuvent être préparés, copiés, publiés et distribués, tout ou en partie, sans aucune restriction. Tous ces documents doivent cependant indiquer le copyright ci-dessus et ce paragraphe. Cependant, ce document en lui-même ne peut-être modifié d'aucune manière, telles que la suppression du copyright, ou des références à la Internet Society ou d'autres organisations de l'Internet. Excepté quand c'est nécessaire dans le cas du développement des standards Internet, dans ce cas, les procédures pour les droits d'auteur définies dans les Standards Internet doivent être suivies, ou quand c'est nécessaire dans le cas d'une traduction vers une langue autre que l'anglais (3).
Les permissions limitées attribuées ci-dessus sont perpétuelles et ne seront pas révoquées par la Internet Society ou ces successeurs ou ayant-droits.
Ce document et les informations qu'il contient sont fournis « tel quel », et la INTERNET SOCIETY ET LE DÉTACHEMENT D'INGÉNIERIE D'INTERNET RÉCUSENT TOUTE GARANTIE, EXPLICITES OU IMPLICITES, INCLUANT SANS LIMITER, LES GARANTIES QUE L'UTILISATION DE L'INFORMATION CONTENUE DANS CE DOCUMENT N'OUTRE-PASSERA AUCUN DROIT OU AUCUNE GARANTIE IMPLICITE, COMMERCIALE OU PARTICULIER.
Remerciements▲
Les fonds pour le fonctionnement de RFC Editor sont actuellement fournis par la Internet Society.
Merci à Neo41 pour sa relecture.