A.1. RFC1459 - Il protocollo IRC

Torna alla sezione precedente

Traduzione di Consuelo Caoduro - Gwendalin on IRCnet
Revisione a cura di Byron
Le note al testo sono di Francesco Messineo al quale si
devono anche numerosi commenti e correzioni.

Network Working Group

J. Oikarinen

Request for commentts: 1459

D. Reed

May 1993

 

Protocollo per l'Internet Relay Chat

Posizione di questo memorandum

Questo memorandum delinea un Protocollo Sperimentale per la comunità di Internet. Discussioni e suggerimenti, per il miglioramento dello stesso, sono graditi. Si prega di fare riferimento all'edizione corrente del "IAB Official Protocol Standards" per la standardizzazione e la definizione della posizione di questo protocollo. La distribuzione di questo memorandum è libera.

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:

  1. <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.
  2. 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.
  3. 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.
  4. 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.
  5. L'ultimo parametro può essere una stringa vuota.
  6. 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.

Passa alla sezione successiva

Torna all'indice

 

 

Copyright © 1997, StallonIt - Ultimo aggiornamento - Gennaio 1999