| Network Working Group |
C. Kalt |
| Request for Comments: 2810 |
April 2000 |
| Updates: 1459 |
|
| Category: Informational |
|
Internet Relay Chat: Architettura
Stato di questa memoria
Questo documento fornisce informazioni per la comunità Internet. Esso non
specifica uno standard Internet di nessun genere. La distribuzione di questo
documento non é 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 é evoluto. Questo documento é 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.
Dalla prima documentazione ufficiale, che risale al Maggio 1993 con l’RFC
1459 [IRC], il protocollo si é evoluto. Questo documento é 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
Index
1. INTRODUZIONE
Il protocollo IRC (Internet Relay Chat) é stato disegnato, in diversi anni,
per costituire un sistema di conferenza basata su testo. Questo documento descrive
l’ architettura corrente.
Il protocollo IRC é basato sul modello client-server, e ben si adatta a girare
su molte macchine in diverse modalità. 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, é anche uno dei maggiori problemi del protocollo, in
quanto handicap serio che limita la massima dimensione che una rete può 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.
Index
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
tra loro [IRC-CLIENT], nonché un punto di collegamento per altri
servers [IRC-SERVER]. Il server é anche responsabile della fornitura
dei servizi di base definiti dal protocollo IRC.
2.2 Clients
Un client é tutto cio’ che si può connettere ad un server, e
che non é un server a sua volta. Vi sono due tipi di clients, ciascuno
usato per una diversa finalità.
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 User 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 sé) agli users. Un
esempio può essere un servizio che raccoglie statistiche circa l’origine
degli utenti connessi alla rete IRC.
Index
3. ARCHITETTURA
Una rete IRC é 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 é 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 ]
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).
Index
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 é
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 é un insieme dotato di nome di uno o piu’ utenti, i quali
riceveranno tutti i messaggi indirizzati a quel canale. Un canale é
caratterizzato dal suo nome e dai membri attuali, nonché da una serie di
proprietà che possono essere manipolate dai (alcuni) suoi membri.
I canali costituiscono un metodo affinché 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 é definito
in “Internet Relay Chat: Channel Management” [IRC-CHAN].
Index
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.
5.1 Localizzatore di client
La comunicazione su base uno-a-uno è solitamente effettuata da clients, dal
momento che la maggior parte del traffico server-server non è il risultato
del reciproco dialogo tra essi. Affinchè sia possibile che i clients
dialoghino tra loro è RICHIESTO che ogni servers sia in grado di inviare un
messaggio in una precisa direzione lungo la struttura ad albero della rete,
così da raggiungere qualsiasi client. Il percorso di un messaggio che viene
inviato è 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 è visto solamente dal server A, che lo
invia direttamente al client 2.
Esempio 2:
Un messaggio tra I clients 1 e 3 è 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 è visto dai servers A, B, C & D, e
solamente dal client 4.
Index
5.2 Uno-a-molti
Lo scopo principale di IRC è 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 User Clients
In IRC il canale ha un ruolo equivalente a quello del gruppo multicast; la
loro esistenza è 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 così 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.
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 è 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 uno schema host/server
Il metodo meno efficiente di una conversazione uno-a-molti è 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 è efficiente come l’utilizzo di un canale
poichè 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.
Index
5.3 Uno-a-tutti
Il tipo di messaggio uno-a-tutti è 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 può produrre un notevole traffico
per far si’ che possa raggiungere tutte le destinazioni desiderate.
Per taluni messaggi non vi è altra possibilità 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.
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
Benchè la maggior parte dei messaggi tra i servers è distribuita a tutti
gli ‘altri’ servers, questo è 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.
Index
6. PROBEMI 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 Scalabilità
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 Affidabilità
Dal momento che l’ unica configurazione di rete ammessa è la struttura
ad albero, ciascun collegamento tra due servers è un punto di guasto ovvio
e piuttosto serio. Questa particolare problematica è richiamata con maggior
dettaglio in “Internet Relay Chat: Server Protocol” [IRC-SERVER].
6.3 Intasamento di rete
Un altro problema che si allaccia alla scalabilità e all’ affidabilità,
così 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 è 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.
Nel tentativo di minimizzare l’impatto di queste problematiche è fortemente
RACCOMANDATO che i servers non tentino automaticamente di riconnettersi troppo
in fretta, così 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 entità, anche il problema della
privacy è una faccenda complicata. Questo è particolarmente vero per i
canali, poichè le informazioni relative sono maggiormente rilevabili
rispetto a se un utente è online o meno.
Index
7. CONSIDERAZIONI SULLA SICUREZZA
Oltre alla questione privacy menzionata nella sezione 6.4 (Privacy), la
sicurezza è ritenuta irrilevante per questo documento.
Index
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
Index
9. RINGRAZIAMENTI
Parti di questo documento sono state copiate dall’ RFC 1459 [IRC] che per
prima ha formalmente documentato il protocollo IRC. Si è 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.
Index
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.
Articolo a cura di :
Roberto "Rob" Timmoneri rob@ircitaly.net
(Traduzione dell'RFC 1459 in lingua originale)
Ultima revisione: 25 Febbraio 2004
|
RFC 2810
