 |
Menu principale |
 |
|
Cartoline virtuali |
|
Cartolina n° 1272
Sono presenti 1307 cartoline virtuali. Entra ora
|
Giochi online |
|
|
News Reader |
|
|
| Network Working Group C. Kalt
Request for Comments: 2810 April 2000
Updates: 1459
Category: Informational
Traduzione a cura di ComiSAT
Brescia, Dic. 2002
(http://www.comisat.it)
Internet Relay Chat: Architettura
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] |
|
|
|
