Riassunto
Il protocollo IRC fu sviluppato durante gli ultimi
4 anni
(1) da quando fu implementato per la prima
volta come mezzo in grado di permettere agli utenti
di parlare tra loro su un BBS (BBS: Bullettin Board
System. è un sistema a gestione privata al quale ci
si può collegare tramite linea telefonica e che mette
a disposizione programmi, dati, aree di messaggi etc..
nell'ambito della cosiddetta telematica amatoriale.-
N.d.T.). Attualmente esso sostiene un network mondiale
di server e clients, e si sta espandendo per far fronte
alla crescente espansione dell'utenza. Negli ultimi
2 anni, il numero medio di utenti connessi al network
IRC principale si è decuplicato. Il protocollo IRC
è un protocollo, basato su stringhe di testo, il cui
interlocutore più semplice consiste in un programma
capace di stabilire una connessione col server.
Torna all'indice
Indice
Torna all'indice
1. INTRODUZIONE
Il protocollo IRC (Internet Relay Chat) è stato progettato
e costruito, con un lavoro durato diversi anni, per
la realizzazione di scambi di messaggi scritti in
tempo reale. Questo documento descrive il protocollo
di IRC attualmente in uso.
(2)
Il protocollo IRC è stato sviluppato su un sistema
che usa il protocollo di rete TCP/IP, senza nessuna
necessità, tuttavia, che questa rimanga il suo solo
ambito di utilizzo. L'IRC stesso è un sistema di teleconferenza
che (mediante l'uso del modello client-server) è stato
adattato per lavorare su molte macchine di modelli
diversi. Un tipico sistema comporta un singolo processo
(il server) che costituisce un punto centrale al quale
i client (o altri server) possono connettersi, realizzando
i necessari invio e distribuzione contemporanea su
più utenti del messaggio ed altre funzioni.
Torna all'indice
1.1 I Servers
Il server forma la spina dorsale di IRC, fornendo
un punto al quale i client possono connettersi per
parlarsi gli uni con gli altri, ed un punto di connessione
per altri server, formando così una rete IRC. L'unica
configurazione di rete permessa ai server di IRC è
quella di un albero [vedi Fig. 1] dove ogni server
agisce come nodo centrale per il resto della rete
che vede.
[ Server 15 ] [ Server 13 ] [ Server 14]
/ \ /
/ \ /
[ Server 11 ] ------ [ Server 1 ] [ Server 12]
/ \ /
/ \ /
[ Server 2 ] [ Server 3 ]
/ \ \
/ \ \
[ Server 4 ] [ Server 5 ] [Server 6 ]
| | \ /
| | \ /
| | \________ /
| | \ /
[ Server 7 ] [ Server 8 ] [ Server 9 ] [ Server 10 ]
:
[ etc. ]
:
[Fig. 1. Configurazione di una rete di server IRC]
Torna all'indice
1.2 I Clients
Si definisce client qualsiasi cosa connessa ad un
server che non sia un altro server. Ogni client si
distingue dagli altri client per un nickname unico,
della lunghezza massima di nove (9) caratteri. Si
vedano le regole grammaticali del protocollo per sapere
quali caratteri si possono e quali non si possono
usare in un nickname. In aggiunta al nickname, tutti
i server devono avere le seguenti informazioni su
ogni client: il vero nome della macchina sulla quale
il programma client viene eseguito, il nome dell'utente
del client di quella macchina, ed il server al quale
il client è connesso.
Torna all'indice
1.2.1 Gli Operatori
Per far sì che il lavoro di rete venga svolto in maniera
sufficientemente ordinata, si permette ad una determinata
classe di client (operatori) di compiere delle funzioni
di manutenzione generale sulla rete. Malgrado i poteri
attribuiti ad un operatore possano essere considerati
"pericolosi", essi sono tuttavia necessari. Gli operatori
dovrebbero essere in grado di compiere operazioni
di base sulla rete, quali lo sconnettere e il riconnettere
servers, per prevenire di un routing non efficiente
sulla rete. Prendendo atto di questa esigenza, il
protocollo qui esposto prevede per gli operatori solo
la capacità di compiere quelle operazioni. Si vedano
le sezioni
4.1.7 (Messaggio
Server Quit) e
4.3.5 (Messaggio
Connect).
Uno dei più controversi, tra i poteri attribuiti agli
operatori è la possibilità di rimuovere "con la forza"
un utente dalla rete: gli operatori sono in grado,
per esempio, di chiudere la connessione tra un qualsiasi
client e il server. La giustificazione per questo
è cosa critica, dal momento che un abuso di questa
possibilità risulta sempre fastidioso e distruttivo.
Per altri dettagli sul' argomento si veda la sezione
4.6.1 (Messaggio
KILL).
Torna all'indice
1.3 I Canali
Un canale è un gruppo, dotato di nome, di uno o più
client dove tutti i membri del gruppo ricevono i messaggi
indirizzati a quel canale. Il canale è automaticamente
creato quando il primo client vi si collega, e cessa
di esistere quando l'ultimo client lo lascia. Durante
il periodo di esistenza del canale ogni client può
riferirsi a quel canale usando il nome dello stesso.
I nomi dei canali sono stringhe (che iniziano con
un "&" oppure con un "#") lunghe fino a 200 caratteri.
A parte la necessità che il primo carattere sia "&"
oppure "#", l'unica restrizione che sussiste per il
nome del canale è che non contenga alcuno spazio ("
"), un control G (^G o ASCII 7), o una virgola (","
la quale è considerata dal protocollo come separatore
tra gli elementi di una lista).
Ci sono due tipi di canali ammessi da questo protocollo.
Uno è un canale assegnato che è conosciuto da tutti
i server che sono connessi alla rete. Questi canali
sono contrassegnati dall' avere come primo carattere
(un #, gli altri sono i cosiddetti canali locali,
il cui nome è preceduto da un carattere & e che)
si distinguono per essere accessibili solo ai client
del server ove il canale esiste. [Ndr - Qui probabilmente
il testo originale a nostra disposizione omette parte
del periodo, ma, dal contesto, si può tentare una
interpretazione che abbiamo inserito tra parentesi
tonde] Questi canali sono distinti dal carattere iniziale
"&". Sono disponibili inoltre diversi modi disponibili
per alterare le caratteristiche dei singoli canali.
Si veda la sezione
4.2.3 (Messaggio
MODE) per maggiori dettagli sull'argomento.
Per creare un nuovo canale o entrare a far parte di
un canale già esistente, un utente entrare (JOIN)
nel canale. Se il canale non preesiste al join, il
canale viene creato ed il creatore del canale diventa
operatore su quel canale. Se invece il canale già
esiste, la richiesta di join al canale viene onorata
o meno dipendentemente dai "modes" in vigore al momento
su quel canale. Per esempio se si tratta di un canale
ad invito (+i), la richiesta verrà accolta solo se
si è stati invitati da qualcuno.
Secondo il protocollo, un utente può accedere a diversi
canali contemporaneamente, ma si raccomanda di non
superare il limite di dieci (10) canali, un confine
ampio, sia per gli esperti che per i novizi. Si veda
la sezione
8.13 per
maggiori informazioni su questo argomento.
(3)
Se qualche ramo della rete IRC si spezza a causa di
uno split (perdita del collegamento) tra due servers,
del canale, su ognuno dei due versanti della rete
divisi dal punto di interruzione, faranno parte solamente
quei client che sono connessi al server sul rispettivo
versante dello split, cessando di farne parte su quello
opposto allo split. Quando il collegamento è ripristinato,
i servers, di nuovo connessi, si comunicano l'un l'altro
la propria lista dei client presenti sul canale i
"modes" di quel canale. Se il canale esiste su tutti
e due i versanti i JOIN e i MODE vengono interpretati
in una maniera inclusiva cosicchè i due versanti della
nuova connessione si troveranno in accordo su quali
client sono nel canale e qual'è l' assetto dei mode
del canale.
Torna all'indice
1.3.1 Gli Operatori di canale
L' operatore di canale (detto anche "chop" o "chanop")
su un dato canale può essere considerato come "proprietario"
di quel canale. A causa di questo loro stato, gli
operatori di canale sono dotati di certi poteri che
li mettono in condizione di mantenere controllo e
una forma di pulizia sul loro canale. Come proprietario
di un canale, ad un operatore non si richiede di render
ragione per le sue azioni, tuttavia se le sue azioni
sono particolarmente antisociali o costituiscono in
qualche modo abuso, potrebbe essere ragionevole chiedere
ad un operatore IRC di intervenire,oppure che gli
utenti semplicemente escano e formino un loro canale.
I soli comandi che possono essere usati dagli operatori
di canale sono:
KICK - Espelle un client
dal canale
MODE - Cambia il mode del canale
INVITE - Invita un client ad un canale ad invito
(mode +i)
TOPIC - Cambia il topic del canale in mode
+t
Un operatore di canale è identificato dal simbolo
'@' posto a fianco del suo nickname ogniqualvolta
esso è associato con un canale (per esempio risponde
ai comandi NAMES, WHO e WHOIS).
Torna all'indice
2. SPECIFICHE IRC
2.1 Generalità
Il protocollo qui descritto realizza sia connessioni
server-server che connessioni client-server. Va detto,
comunque, che ci sono più restrizioni nelle connessioni
client-server (che sono considerate inattendibili)
che in quelle server-server.
Torna all'indice
2.2 Codici dei caratteri
Nessun set particolare di caratteri è specificato.
Il protocollo è basato su un sistema di codici composti
da otto (8) bits, vale a dire un ottetto (byte). Ogni
messaggio può essere composto da un numero qualsiasi
di questi ottetti, sebbene i valori di alcuni ottetti
vengano usati come codici di controllo, che svolgono
il ruolo di delimitatori dei messaggi. Indipendentemente
dal fatto di essere un protocollo a 8 bits, i delimitatori
dei messaggi e i comandi sono organizzati in maniera
tale da rendere il protocollo maggiormente utilizzabile
da terminali USASCII e da connessioni telnet.
A causa dell'origine scandinava di IRC, i caratteri
{} e | sono considerati essere l'equivalente minuscolo
dei caratteri [] e \. Questo problema crea una situazione
critica quando si tratta di determinare l'equivalenza
di due nickname.
Torna all'indice
2.3 Messaggi
I server e i client si scambiano messaggi che possono
generare o meno una risposta. Se il messaggio contiene
un comando valido, come descritto nelle prossime sezioni,
il client dovrebbe aspettarsi una risposta coerente
con le specifiche, ma non è consigliabile che attende
la replica del server per un tempo illimitato, poichè
le comunicazioni client-server e server-server sono
di natura essenzialmente asincrona.
Ogni messaggio IRC può essere consistere fondamentalmente
di tre parti: il prefisso (facoltativo), il comando,
ed i parametri del comando (ve ne possono essere fino
a 15). Il prefisso, il comando e tutti i parametri
sono separati da uno (o più) caratteri "spazio" (ASCII:
0x20).
La presenza di un prefisso è indicata con un singolo
carattere due punti (":"), (ASCII: 0x3b), in prima
posizione. Non ci devono essere lacune (spazi bianchi)
tra i due punti ed il prefisso.
Il prefisso è usato dai server per specificare la
vera origine del messaggio. Se manca il prefisso,
si assume che il messaggio abbia avuto origine dalla
connessione sulla quale è stato ricevuto. Non è necessario
che un client premetta un prefisso quando inviano
un messaggio: se usano un prefisso, l'unico prefisso
valido è il nickname registrato ed associato con quel
client. Se la sorgente identificata dal prefisso non
può essere trovata nel database interno del server,
oppure se la sorgente è registrata su un link differente
da quello da cui arriva il messaggio, il server deve
tacitamente ignorare il messaggio.
Il comando deve essere o un comando IRC valido, oppure
deve essere un numero di tre (3) cifre rappresentato
in codice ASCII. I messaggi IRC sono linee di caratteri
che terminano sempre con una coppia CR-LF (Ritorno
a capo - Salto di riga), e non devono eccedere i 512
caratteri in lunghezza, compresi tutti i caratteri
inclusi i caratteri di coda CR-LF. Perciò il massimo
numero di caratteri permesso per ogni riga di comando
con gli eventuali parametri è di 510. Non c' è la
possibilità di usare linee di continuazione per i
messaggi. Si veda la
sezione 7
per maggiori informazioni sulle implementazioni correnti.
Torna all'indice
2.3.1 Formato dei messaggi in 'pseudò BNF
I messaggi del protocollo devono essere estratti dal
flusso continuo di ottetti. La soluzione attuale consiste
nel designare due caratteri, CR e LF (ritorno a capo
e salto di linea), come separatori di messaggi. I
messaggi vuoti sono tacitamente ignorati, il che permette
l'uso della sequenza CR-LF tra i messaggi senza ulteriori
problemi.
Il messaggio estratto è scomposto ed analizzato nei
componenti: (prefisso), (comando) e lista di parametri
uniti fra loro da componenti <intermedi> o <iniziali>.
Per tanto la rappresentazione BNF [Ndr - Backus Normal
Form] di questo assetto è:
- <messaggio> ::=
- [':' <prefisso> <SPAZIO> ] <Comando>
<parametri> <crlf>
- <prefisso> ::=
- <nome-del-server> | <nick> [ '!'
<utente> ] [ '@' <macchina> ]
- <Commando> ::=
- <lettera> { <lettera> } | <numero>
<numero> <numero>
- <SPAZIO> ::=
- ' ' { ' ' }
- <parametri> ::=
- <SPAZIO> [ ':' <iniziali> | <intermedi>
<parametri> ]
- <intermedi> ::=
- < Qualsiasi sequenza *non vuota* di ottetti
che non includa i caratteri SPAZIO, NUL (zero
binario), CR, LF e il cui primo carattere non
può essere ':'>
- <iniziali> ::=
- <Qualsiasi sequenza di ottetti, anche *vuota*,
che non includa NUL o CR o LF>
- <crlf> ::=
- CR LFG
Note:
- <SPAZIO> consiste solo del(i) carattere(i)
SPAZIO (0x20). Nota bene che la TABULAZIONE, e
tutti gli altri caratteri di controllo sono considerati
SPAZI NON BIANCHI.
- Dopo aver estratto la lista di parametri, tutti
i parametri sono equivalenti, non ha importanza
che essi si possano associare con <intermedi>
o <iniziali>. <Iniziali> è solamente
un espediente sintattico per permettere lo SPAZIO
tra i parametri.
- Il fatto che CR e LF non possono apparire nel
contesto dei parametri è solo un fatto dipendente
dalla modalità di delimitazione del comando. Questo
potrebbe cambiare in futuro.
- Il carattere NUL non ha significato speciale
nella composizione dei messaggi, e, in linea di
principio, potrebbe essere parte di un parametro,
causando però delle difficoltà nel normale trattamento
delle stringhe in linguaggio "C". Questo è l'
unico motivo per cui non è permesso l'uso del
carattere NUL all'interno dei messaggi.
- L'ultimo parametro può essere una stringa vuota.
- L'uso del prefisso esteso (['!' <user>
] ['@' <host> ]) non deve essere usato nelle
comunicazioni server-server, ed è previsto solo
nell'ambito della comunicazione server- client
in modo da fornire ai client maggiori informazioni
utili riguardo la provenienza del messaggio, senza
necessità di ulteriori domande.
Gran parte dei messaggi previsti dal protocollo specificano
semantica e sintassi addizionali, dettata dalla loro
posizione nella lista, per le stringhe dei parametri.
Per esempio, molti comandi dei server assumono che
il primo parametro dopo il comando è una lista di
obbiettivi, così organizzata:
- <obbiettivo> ::=
- <a> [ "," <obbiettivo> ]
- <a> ::=
- <canale> | <utente> '@' <nome-del-server>
| <nick> | <maschera>
- <channel> ::=
- ('#' | '&') <stringa-di-caratteri>
- <nome-del-server> ::=
- <macchina>
- <macchina> ::=
- si veda l' RFC 952 [DNS:4] per dettagli sui
nomi-macchina permessi
- <nick> ::=
- <lettera> { <lettera> | <numero>
| <carattere-speciale> }
- <maschera> ::=
- ('#' | '$') <stringa-di-caratteri (contenente
eventuali "*" e "?")>
- <stringa-di-caratteri> ::=
- <qualsiasi sequenza di ottetti tranne SPACE,
BELL, NUL, CR, LF e virgola (',')>
Ulteriori elementi sintattici dei parametri sono:
- <utente> ::=
- <nonbianco> { <nonbianco> }
- <lettera> ::=
- 'a' ... 'z' | 'a' ... 'Z'
- <numero> ::=
- '0' ... '9'
- <speciale> ::=
- '-' | '[' | ']' | '\' | '`' | '^' | '{' | '}'
- <nonbianco> ::=
- <ogni codice 8bit tranne SPACE (0x20), NUL
(0x0), CR (0xd) e LF(0xa)>
Torna all'indice
2.4 Risposte numeriche
La maggior parte dei messaggi inviati al server generano
una risposta di qualche sorta. La risposta più frequente
è una risposta numerica, usata sia per risposte normali
che di errore. La risposta numerica deve essere inviata
come un messaggio consistente del prefisso del mittente,
le tre cifre numeriche e la destinazione della risposta.
Non è permesso che una risposta numerica abbia origine
da un client; qualsiasi messaggio di questo genere
ricevuto da un server viene tacitamente ignorato.
Sotto tutti gli altri aspetti la risposta numerica
è simile ad un normale messaggio, con la sola differenza
che la parola-chiave è formata da tre cifre numeriche
invece che da una stringa di lettere. Una lista delle
possibili risposte è contenuta nella sezione 6.
Torna all'indice
3. CONCETTI DI IRC
Questa sezione è dedicata all' esposizione dei concetti
su cui si basa l' organizzazione del protocollo IRC
e come le implementazioni attualmente in uso inoltrino
le differenti categorie di messaggi.
1--\
A D---4
2--/ \ /
B-------C
/ \
3 E
Servers: A, B, C, D, E Clients: 1, 2, 3, 4
[ Fig. 2. Esempio di una rete IRC di piccole dimensioni]
Torna all'indice
3.1 Comunicazione uno a uno
La comunicazione uno a uno è realizzata di solito
dai clients, dal momento che la maggior parte del
traffico server a server non è il risultato di server
che parlino esclusivamente tra loro. Per dare ai client
la possibilità di parlare loro, è necessario che tutti
i server siano in grado di inviare un messaggio in
una direzione precisa lungo la struttura ad albero
della rete, in modo da poter raggiungere qualsiasi
client. Il percorso di un messaggio inviato è quello
più corto tra due punti qualsiasi della struttura.
Gli esempi che seguono fanno riferimento alla Figura
2.
- Esempio 1:
- Un messaggio tra i client 1 e 2 è visto solo
dal server A, il quale lo invia direttamente al
client 2.
- Esempio 2:
- Un messaggio tra i client 1 e 3 è visto dai
server A e B, e dal client 3. A nessun altro server
o client è permesso di vedere il messaggio.
- Esempio 3:
- Un messaggio tra i client 2 e 4 è visto dai
server A, B, C e D, e solamente dal client 4.
Torna all'indice
3.2 Uno a molti
Lo scopo principale di IRC è di realizzare un luogo
pubblico di incontro nell' ambito del quale sia possibile,
in maniera semplice ed efficiente, lo scambio di messaggi
fra più persone (conversazione uno a molti).
A questo proposito IRC offre diversi mezzi, ognuno
dei quali è orientato al raggiungimento di uno specifico
scopo.
Torna all'indice
3.2.1 Ad una lista
Il tipo di conversazione uno-a-molti meno efficiente
consiste nel parlare, attraverso i clients, ad una
"lista" di utenti. Come questo avvenga è piuttosto
banale: il client fornisce una lista di destinazioni
alle quali il messaggio deve essere inviato ed il
server lo "moltiplica", inviando delle copie separate
del messaggio ad ogni destinazione data.
Questo sistema non è efficiente come quello della
conversazione uno ad un gruppo, dal momento che la
lista di destinazione viene considerata come composta
da tante singole destinazioni e l'invio dei messaggi
avviene senza controllare che non vengano inviati
dei duplicati lungo i possibili percorsi.
Torna all'indice
3.2.2 Ad un gruppo (canale)
In IRC il canale ha il ruolo equivalente a quello
di un gruppo ad invio multiplo; la sua esistenza è
dinamica (sussistendo e/o cessando in funzione del
fatto che gli utenti siano presenti o lascino il canale)
e la conversazione in corso in un canale è inviata
solo a quei server cui siano collegati utenti di un
canale dato. Se ci sono più utenti sullo stesso server
per lo stesso canale, il messaggio è inoltrato solamente
una volta a quel server e poi inviato ad ognuno dei
client del canale. Questa operazione viene poi ripetuta
per ogni combinazione client-server finchè il messaggio
originale non sia stato diffuso ed abbia raggiunto
ogni membro del canale.
I seguenti esempi fanno riferimento alla figura 2.
- Esempio 4:
- Ogni canale con 1 solo client presente. I messaggi
al canale vanno al server e da nessun altra parte.
- Esempio 5:
- 2 client in un canale. Tutti i messaggi attraversano
un percorso come se fossero messaggi privati tra
i due client a prescindere dal canale.
- Esempio 6:
- Client 1, 2 e 3 dentro un canale. Tutti i messaggi
al canale sono inviati a tutti i client e solo
a quei server che devono essere attraversati dal
messaggio come se esso fosse un messaggio privato
ad un singolo client. Se il client 1 manda un
messaggio, esso arriva al client 2 e poi, tramite
il server B, al client 3.
Torna all'indice
3.2.3 Ad uno schema macchina-utente/server
Per fornire gli operatori di IRC di un qualche meccanismo
per inviare messaggi ad un novero consistente di utenti,
i messaggi stessi vengono corredati di "schemi macchina-utente
e server". Questi messaggi sono inviati agli utenti
per i quali le informazioni sulla macchina o sul server
corrispondono a quelle dello schema. I messaggi vengono
inviati solo alla locazione ove si trovano gli tenti,
in un modo simile a quello usato per i canali.
Torna all'indice
3.3 Uno a tutti
Il tipo di messaggio uno a tutti è meglio denotato
come un messaggio diffuso, inviato a tutti i client
o/e a tutti i servers. In una rete di server e utenti
di grandi dimensioni, un messaggio singolo può dar
luogo ad un rilevante volume di traffico, nel momento
in cui viene inviato attraverso la rete, per poter
raggiungere tutte le destinazioni desiderate.
Per alcuni messaggi non c' è altra soluzione che diffonderli
a tutti i servers, affinchè le informazioni di stato
contenute da ogni server siano ragionevolmente coerenti
tra i server stessi.
Torna all'indice
3.3.1 Client a Client
Non c' è alcuna categoria di messaggi per la quale,
partendo da un messaggio singolo, derivi un messaggio
che sia inviato ad ogni altro client.
Torna all'indice
3.3.2 Client a Server
La maggior parte dei comandi che risultano nello scambio
di informazioni di stato (quali appartenenza ad un
canale, mode del canale, status dell' utente ecc.)
deve, per default, essere inviata a tutti i server,
e questa distribuzione non dovrebbe essere cambiata
dal client.
Torna all'indice
3.3.3 Server a Server.
Se la maggior parte dei messaggi tra due server viene
distribuita a tutti gli "altri" server, questo è in
effetti richiesto solamente per ogni messaggio che
abbia effetto su un utente, un canale o un server.
Dal momento che queste sono le voci base che si trovano
in IRC, la quasi totalità dei messaggi originati da
un server vengono distribuiti a tutti gli altri server
connessi.
Torna all'indice