RFC IRC : Problèmes actuels

Il y a nombre de problèmes reconnus avec ce protocole, chacun d'entre eux espérant être résolu dans un futur proche lors de sa réécriture. Actuellement, le travail est en cours pour trouver des solutions convenables à ces problèmes.

9.1 Localisation

Il est largement reconnu que ce protocole ne gère pas correctement les localisations lorsqu'il est utilisé dans une grande arène. Le problème principal vient de la nécessité qu'ont tous les serveurs de connaître tous les autres serveurs et utilisateurs, et que leurs informations soient mises à jour dès que possible. Il est aussi nécessaire de garder un faible nombre de serveurs, de façon à ce que le chemin entre deux points reste aussi faible que possible, et que l'arbre de distribution contienne des branches aussi grosses que possible.

9.2 Identifiants

Le protocole IRC courant a trois types d'identifiants : le pseudonyme, le nom de canal, et le nom de serveur. Chacun de ses trois types a son propre domaine, et aucun doublon n'est autorisé dans ce domaine. Actuellement, il est possible pour un utilisateur de prendre l'identifiant pour n'importe laquelle des trois, ce qui résulte en une collision. Il est largement reconnu que cela nécessite des modifications, et le plan actuel prévoit des noms uniques pour les canaux et les pseudo n'entrent pas en collision, ainsi qu'une solution autorisant un arbre cyclique.

9.2.1 Pseudonymes

L'idée de pseudonymes sur IRC est très pratique pour les utilisateurs qui parlent hors des canaux, mais il y a un nombre fini des pseudonymes, et il n'est pas rare de voir plusieurs personne vouloir utiliser le même pseudo. Si un pseudonyme est choisi par deux personnes qui utilisent ce protocole, soit l'une des deux ne réussi pas à l'obtenir, soit toutes les deux sont déconnectées par l'utilisation de KILL (4.6.1).

9.2.2 Canaux

La couche de canaux actuelle nécessite que tous les serveurs connaissent tous les canaux, leurs membres, et leurs propriétés. En plus ne pas bien gérer la localisation la question de la confidentialité est aussi concernée. La collision de canaux est gérée de façon inclusive (les deux personnes qui créent le canal sont considérés comme en étant membre) plutôt que de façon exclusive telle que celle utilisée pour résoudre les collisions de pseudonymes.

9.2.3 Serveurs

Bien que le nombre de serveurs soit habituellement petit comparé au nombre d'utilisateurs et de canaux, ils doivent aussi être connus globalement, soit chacun séparément, soit caché derrière un masque.

9.3 Algorithmes

A certains endroits du code du serveur, il n'a pas été possible d'éviter des algorithmes N^2, comme par exemple dans la vérification de la liste des canaux d'un ensemble de clients.

Dans les versions actuelles du serveur, il n'y a pas vérification de base de données, chaque serveur assumant qu'un serveur voisin est correct. Cela ouvre la porte à de gros problèmes si un serveur qui se connecte est bogué ou essaie d'introduire des contradictions dans le réseau existant.

Actuellement, en raison du manque d'étiquettes internes et globales uniques, il existe une multitude de conditions pouvant causer une désynchronisation. Ces conditions résultent généralement du temps pris par un message pour traverser le réseau IRC. Mais, même en changeant pour des étiquettes uniques, il y a des problèmes de synchronisation avec les commandes liées aux canaux.

Annonces