Network Working Group C. Kalt Request for Comments: 2810 April 2000 Updates: 1459 Category: Informational Internet Relay Chat: Architettura Traduzione a cura di ComiSAT Brescia, Dic. 2002 (comisat@yahoo.it) Distribuita da .::http://www.rfc.altervista.org::. Stato di questa memoria Questo documento fornisce informazioni per la comunita’ Internet. Esso non specifica uno standard Internet di nessun genere. La distribuzione di questo documento non e’ soggetta a limitazioni. Copyright Copyright (C) The Internet Society (2000). Tutti i diritti riservati. Sunto Il protocollo IRC (Internet Relay Chat) viene utilizzato per costituire un sistema di conferenza basata su testo. E’ stato sviluppato nel 1989 quando fu in origine implementato per fara chattare gli utenti di una BBS. Dalla prima documentazione ufficiale, che risale al Maggio 1993 con l’RFC 1459 [IRC], il protocollo si e’ evoluto. Questo documento e’ un aggiornamento che descrive l’architettura dell’attuale protocollo IRC ed il ruolo dei suoi diversi componenti. Altri documenti descrivono in dettaglio il protocollo utilizzato tra i vari componenti qui definiti. Tavola dei contenuti 1. Introduzione ............................................... 2 2. Componenti ................................................. 2 2.1 Servers ................................................ 2 2.2 Clients ................................................ 3 2.2.1 User Clients ...................................... 3 2.2.2 Service Clients ................................... 3 3. Architettura ............................................... 3 4. Servizi del protocollo IRC ................................. 4 4.1 Localizzatore di client ................................ 4 4.2 Trasmissione del messaggio.............................. 4 4.3 Hosting e amministrazione di un canale ................. 4 5. Concetti di IRC ............................................ 4 5.1 Comunicazione uno-a-uno ................................ 5 5.2 Uno-a-molti ............................................ 5 5.2.1 Ad un canale ...................................... 5 5.2.2 Ad uno schema host/server ......................... 6 Kalt Informational [Page 1] RFC 2810 Internet Relay Chat: Architecture April 2000 5.2.3 Ad una lista ...................................... 6 5.3 Uno-a-tutti ............................................ 6 5.3.1 Client-a-Client ................................... 6 5.3.2 Client-a-Server ................................... 7 5.3.3 Server-a-Server ................................... 7 6. Problemi attuali ........................................... 7 6.1 Scalabilita’ ........................................... 7 6.2 Affidabilita’ .......................................... 7 6.3 Intasamenti di rete .................................... 7 6.4 Privacy ................................................ 8 7. Considerazioni sulla sicurezza ............................. 8 8. Attuale supporto e disponibilita’ .......................... 8 9. Ringraziamenti ............................................. 8 10. Riferimenti ............................................... 8 11. Indirizzo dell’autore ..................................... 9 12. Riporto integrale del Copyright ........................... 10 1. Introduzione Il protocollo IRC (Internet Relay Chat) e’ stato disegnato, in diversi anni, per costituire un sistema di conferenza basata su testo. Questo documento descrive l’architettura corrente. Il protocollo IRC e’ basato sul modello client-server, e ben si adatta a girare su molte macchine in diverse modalita’. Una tipica configurazione prevede un singolo processo (il server) che costituisce un punto di connessione centrale per i clients (a altri servers), che effettua la distribuzione/multiplexing dei messaggi richiesti, e altre funzioni. Tale modello, che richiede che ciascun server abbia una copia della globale informazione di stato, e’ anche uno dei maggiori problemi del protocollo, in quanto handicap serio che limita la massima dimensione che una rete puo’ raggiungere. Se le reti esistenti sono state in grado di crescere con passi da gigante il merito va all’industria dell’hardware, che ci ha fornito sistemi sempre piu’ potenti. 2. Componenti I paragrafi che seguono definiscono i componenti di base del protocollo IRC. 2.1 Servers Il server costituisce la spina dorsale di IRC in quanto unico componente del protocollo in grado di collegare tra loro tutti gli altri componenti: esso costituisce un punto al quale i clients si possono connettere per dialogare Kalt Informational [Page 2] RFC 2810 Internet Relay Chat: Architecture April 2000 tra loro [IRC-CLIENT], nonche’ un punto di collegamento per altri servers [IRC-SERVER]. Il server e’ anche responsabile della fornitura dei servizi di base definiti dal protocollo IRC. 2.2 Clients Un client e’ tutto cio’ che si puo’ connettere ad un server, e che non e’ un server a sua volta. Vi sono due tipi di clients, ciascuno usato per una diversa finalita’. 2.2.1 User Clients Gli user clients (‘clients utente’) sono di solito dei programmi che forniscono un’interfaccia basata su testo, usati per comunicare interattivamente via IRC. A questa particolare categoria di clients ci si riferisce spesso come “users” (utenti). 2.2.2 Service Clients A differenza degli users, i service clients (‘clients di servizi’) non sono concepiti per essere utilizzati a dialogare. Essi hanno un accesso piu’ limitato alle funzioni chat del protocollo, mentre hanno accesso facoltativo a dati maggiormente privati sui servers. I services sono generalmente automazioni usate per fornire qualche sorta di servizio (non necessariamente relativo all’IRC in se’) agli users. Un esempio puo’ essere un servizio che raccoglie statistiche circa l’origine degli utenti connessi alla rete IRC. 3. Architettura Una rete IRC e’ definita da un gruppo di servers connessi tra loro. Un singolo server forma la rete IRC piu’ semplice. La sola configurazione di rete permessa per gli IRC servers e’ quella della struttura ad albero, ove ciascun server funge da nodo centrale per il resto della rete che vede. 1--\ A D---4 2--/ \ / B----C / \ 3 E Servers: A, B, C, D, E Clients: 1, 2, 3, 4 [ Fig. 1. Esempio di piccola rete IRC ] Kalt Informational [Page 3] RFC 2810 Internet Relay Chat: Architecture April 2000 L’implementazione del protocollo IRC nella comunicazione diretta tra due clients non ha alcun senso. Tutta la comunicazione tra clients passa attraverso il/i server(s). 4. Servizi del protocollo IRC Questa sezione descrive i servizi offerti dal protocollo IRC. La combinazione di tali servizi consente conferenze in tempo reale (real-time). 4.1 Localizzatore di client Per potersi scambiare messaggi due clients devono essere in grado di localizzarsi a vicenda. Una volta collegatosi ad un server un client si registra tramite un’etichetta che viene poi usata da altri servers e clients per sapere dove il client e’ localizzato. 4.2 Trasmissione del messaggio L’implementazione del protocollo IRC nella comunicazione diretta tra due clients non ha alcun senso. Tutta la comunicazione tra clients passa attraverso il/i server(s). 4.3 Hosting e amministrazione di un canale Un canale e’ un insieme dotato di nome di uno o piu’ utenti, i quali riceveranno tutti i messaggi indirizzati a quel canale. Un canale e’ caratterizzato dal suo nome e dai membri attuali, nonche’ da una serie di proprieta’ che possono essere manipolate dai (alcuni) suoi membri. I canali costituiscono un metodo affinche’ un messaggio possa essere inviato a svariati clients. I server, ospitando i canali, forniscono il multiplexing del messaggio. I servers sono anche responsabili della gestione dei canali, tenendo traccia dei membri del canali. L’esatto ruolo dei servers e’ definito in “Internet Relay Chat: Channel Management” [IRC-CHAN]. 5. Concetti di IRC Questa sezione si occupa di descrivere gli attuali concetti che stanno dietro l’organizzazione del protocollo IRC e come vengono distribuite differenti classi di messaggi. Kalt Informational [Page 4] RFC 2810 Internet Relay Chat: Architecture April 2000 5.1 Comunicazione uno-a-uno La comunicazione su base uno-a-uno e’ solitamente effettuata da clients, dal momento che la maggior parte del traffico server-server non e’ il risultato del reciproco dialogo tra essi. Affinche’ sia possibile che i clients dialoghino tra loro e’ RICHIESTO che ogni servers sia in grado di inviare un messaggio in una precisa direzione lungo la struttura ad albero della rete, cosi’ da raggiungere qualsiasi client. Il percorso di un messaggio che viene inviato e’ quello piu’ corto tra i due punti da collegare della struttura ad albero. Gli esempi che seguono fanno tutti riferimento alla Figura 1 di cui sopra. Esempio 1: Un messaggio tra i clients 1 e 2 e’ visto solamente dal server A, che lo invia direttamente al client 2. Esempio 2: Un messaggio tra I clients 1 e 3 e’ visto dai servers A & B, e il client 3. Nessun altro client o server vede il messaggio. Esempio 3: Un messaggio tra I clients 2 e 4 e’ visto dai servers A, B, C & D, e solamente dal client 4. 5.2 Uno-a-molti Lo scopo principale di IRC e’ fornire un forum che consenta conferenze semplici ed efficienti (conversazione uno-a-molti). IRC offre svariati modi per poter far questo, ciascuno dei quali ha un preciso obiettivo. 5.2.1 Ad un canale In IRC il canale ha un ruolo equivalente a quello del gruppo multicast; la loro esistenza e’ dinamica (N.d.T. - viene e va a seconda che gli utenti si uniscano o abbandonino il canale) e la conversazione in corso su un canale DEVE essere inviata solamente ai servers che stanno sostenendo gli utenti sul dato canale. Il messaggio, inoltre, SARA’ inviato solamente una volta a tutti i collegamenti locali cosi’ che ciascun server sia responsabile di scompartimentare il messaggio originale per assicurare che esso raggiunga tutti i destinatari. Gli esempi che seguono fanno tutti riferimento alla Figura 2. Esempio 4: Un qualsiasi canale con 1 solo client presente. I messaggi al canale vanno al server e da nessun’altra parte. Esempio 5: Due clients su un canale. Tutti i messaggi seguono un percorso come se fossero messaggi privati tra i due clients esterni al canale. Kalt Informational [Page 5] RFC 2810 Internet Relay Chat: Architecture April 2000 Esempio 6: Client 1, 2 e 3 su un canale. Tutti i messaggi al canale sono inviati a tutti i clients e solo a quei servers che devono essere attraversati dal messaggio se questo e’ privato verso un singolo client. Se il client 1 invia un messaggio, questo raggiunge il client 2 e, via server B, al client 3. 5.2.2 Ad uno schema host/server Per fornire qualche sorta di meccanismo che permetta di inviare messaggi ad un grande numero di utenti, sono previsti messaggi con schema host e server. Tali messaggi vengono spediti a quegli utenti le cui informazioni host o server corrispondono a quelle dello schema. I messaggi vengono trasmessi solamente alle posizioni in cui si trovano gli utenti, in maniera simile al modo usato per i canali. 5.2.3 Ad una lista Il metodo meno efficiente di una conversazione uno-a-molti e’ un client che parla ad una ‘lista’ di destinatari (clients, canali, schemi). Come questo avviene si spiega da solo: il client fornisce una lista di destinazioni alla quale il messaggio dev’essere recapitato ed il server invia copie separate dello stesso a ciascuna destinazione data. Questo metodo non e’ efficiente come l’utilizzo di un canale poiche’ la lista di destinazioni POTREBBE essere spezzata (N.d.T. – dal server per determinare ogni singola destinazione) e il messaggio inviato senza alcun controllo che eviti l’invio di duplicati. 5.3 Uno-a-tutti Il tipo di messaggio uno-a-tutti e’ meglio descrivibile come un messaggio broadcast, inviato a tutti i clients o servers o entrambi. In un’estesa rete di clients e servers, un singolo messaggio puo’ produrre un notevole traffico per far si’ che possa raggiungere tutte le destinazioni desiderate. Per taluni messaggi non vi e’ altra possibilita’ che inviarli a tutti i servers in modo che le informazioni di stato di ciascun server siano ragionevolmente coerenti tra loro. 5.3.1 Client-a-Client Non vi sono tipologie di messaggio per cui un singolo messaggio venga inviato a tutti gli altri client. Kalt Informational [Page 6] RFC 2810 Internet Relay Chat: Architecture April 2000 5.3.2 Client-a-Server La maggior parte dei comandi che risultano in uno scambio di informazioni di stato (come membri del canale, modi del canale, stato dell’utente, ecc.) DEVE essere inviata per default a tutti i servers, e tale operazione NON POTRA’ essere modificata dal client. 5.3.3 Server-a-Server Benche’ la maggior parte dei messaggi tra i servers e’ distribuita a tutti gli ‘altri’ servers, questo e’ richiesto solamente per quei messaggi che incidono su un utente, un canale od un server. Dal momento che questi sono gli elementi fondamentali di IRC, quasi tutti i messaggi originati da un server vengono inoltrati a tutti gli altri servers connessi. 6. Problemi attuali Vi sono un certo numero di problemi riscontrati con questo protocollo; questa sezione si occupa solamente dei problemi relazionati all’architettura dello stesso. 6.1 Scalabilita’ E’ ampiamente riconosciuto che questo protocollo non scala sufficientemente bene se usato in una grande arena. Il problema principale proviene dall’esigenza che tutti i servers conoscano di tutti gli altri servers, utenti e canali e che le informazioni loro riguardanti siano aggiornate non appena sono modificate. 6.2 Affidabilita’ Dal momento che l’unica configurazione di rete ammessa e’ la struttura ad albero, ciascun collegamento tra due servers e’ un punto di guasto ovvio e piuttosto serio. Questa particolare problematica e’ richiamata con maggior dettaglio in “Internet Relay Chat: Server Protocol” [IRC-SERVER]. 6.3 Intasamento di rete Un altro problema che si allaccia alla scalabilita’ e all’affidabilita’, cosi’ come all’architettura ad albero, riguarda il fatto che il protocollo e l’architettura di IRC sono estremamente vulnerabili da instasamenti di rete. Questo problema e’ endemico, e dovrebbe essere risolto per la prossima generazione: se il sovraccarico e l’alto volume di traffico causa un intoppo del collegamento tra due servers non solo genera un incremento di traffico, ma causa inoltre che la riconnessione (eventualmente altrove) dei due servers generi a sua volta ulteriore traffico. Kalt Informational [Page 7] RFC 2810 Internet Relay Chat: Architecture April 2000 Nel tentativo di minimizzare l’impatto di queste problematiche e’ fortemente RACCOMANDATO che i servers non tentino automaticamente di riconnettersi troppo in fretta, cosi’ da evitare l’aggravamento della situazione. 6.4 Privacy Oltre al fatto che non scalino bene, il fatto che i servers necessitino di conoscere tutte le informazioni delle altre entita’, anche il problema della privacy e’ una faccenda complicata. Questo e’ particolarmente vero per i canali, poiche’ le informazioni relative sono maggiormente rilevabili rispetto a se un utente e’ online o meno. 7. Considerazioni sulla sicurezza Oltre alla questione privacy menzionata nella sezione 6.4 (Privacy), la sicurezza e’ ritenuta irrilevante per questo documento. 8. Attuale supporto e disponibilita’ Mailing lists per discussioni relative ad IRC: General discussion: ircd-users@irc.org Protocol development: ircd-dev@irc.org Implementazioni software: ftp://ftp.irc.org/irc/server ftp://ftp.funet.fi/pub/unix/irc ftp://coombs.anu.edu.au/pub/irc Newsgroup: alt.irc 9. Ringraziamenti Parti di questo documento sono state copiate dall’RFC 1459 [IRC] che per prima ha formalmente documentato il protocollo IRC. Si e’ inoltre beneficiato di numerose analisi e commenti. In particolare, le persone di seguito elencate hanno dato a questo documento un contributo significativo: Matthew Green, Michael Neumayer, Volker Paulsen, Kurt Roeckx, Vesa Ruokonen, Magnus Tjernstrom, Stefan Zehl. Kalt Informational [Page 8] RFC 2810 Internet Relay Chat: Architecture April 2000 10. Riferimenti [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. 11. Indirizzo dell’autore Christophe Kalt 99 Teaneck Rd, Apt #117 Ridgefield Park, NJ 07660 USA EMail: kalt@stealth.net Kalt Informational [Page 9] RFC 2810 Internet Relay Chat: Architecture April 2000 12. Riporto integrale del Copyright (in lingua originale) Copyright (C) The Internet Society (2000). All rights reserved. This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English. The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assigns. This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. Acknowledgement Funding for the RFC Editor function is currently provided by the Internet Society. Kalt Informational [Page 10]