| Network Working Group J. Oikarinen
Request per Commandnts: 1459 D. Reed May 1993
Protocollo per l' Internet
Relay Chat
Posizione di questo memorandum
Questo memorandum delinea un Protocollo Sperimentale per la comunita' 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 e' 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. E' un sistema a gestione privata al quale ci si puo' 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 servers 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 e' decuplicato.
Il protocollo IRC e' un protocollo, basato su stringhe di testo, il cui interlocutore piu'
semplice consiste in un programma capace di stabilire una connessione col server.
Indice:
1. INTRODUZIONE 4
1.1 I Servers 4
1.2 I Clients 4
1.2.1 Gli Operatori 5
1.3 I Canali 5
1.3.1 Gli Operatori di canale 6
2. SPECIFICHE IRC 6
2.1 Generalita' 6
2.2 Codici dei caratteri 6
2.3 Messaggi 7
2.3.1 Formato dei messaggi in 'pseudo' BNF 7
2.4 Risposte numeriche 8
3. CONCETTI DI IRC 9
3.1 La Comunicazione uno a uno 9
3.2 La Comunicazione Uno a molti 9
3.2.1 Verso una lista 10
3.2.2 Verso un gruppo (canale) 10
3.2.3 Verso un host/server mask 10
3.3 Uno a tutti 10
3.3.1 Comunicazione Client-Client 11
3.3.2 Comunicazione Client-Server 11
3.3.3 Comunicazione Server-Server 11
4. INFORMAZIONI DETTAGLIATE SUI SINGOLI MESSAGGI 11
4.1 Registrazione di connessione 11
4.1.1 Messaggio Password 12
4.1.2 Messaggio Nickname 12
4.1.3 Messaggio User 13
4.1.4 Messaggio Server 14
4.1.5 Messaggio Operator 14
4.1.6 Messaggio Quit 15
4.1.7 Messaggio Server Quit 15
4.2 Operazioni sul canale 16
4.2.1 Messaggio Join 17
4.2.2 Messaggio Part 18
4.2.3 Messaggio Mode 18
4.2.3.1 Modi dei canali 18
4.2.3.2 Modi dell'utente 19
4.2.4 Messaggio Topic 20
4.2.5 Messaggio Names 20
4.2.6 Messaggio List 21
4.2.7 Messaggio Invite 21
4.2.8 Messaggio Kick 22
4.3 Comandi e Richieste di informazioni sul server 22
4.3.1 Messaggio Version 23
4.3.2 Messaggio Stats 23
4.3.3 Messaggio Links 24
4.3.4 Messaggio Time 25
4.3.5 Messaggio Connect 25
4.3.6 Messaggio Trace 26
4.3.7 Messaggio Admin 27
4.3.8 Messaggio Info 27
4.4 Invio di messaggi 28
4.4.1 Messaggi Privati 28
4.4.2 Messaggi Notice 29
4.5 Richieste di informazioni sull'utente 29
4.5.1 Richiesta Who 29
4.5.2 Richiesta Whois 30
4.5.3 Messaggio Whowas 30
4.6 Altri messaggi 31
4.6.1 Messaggio Kill 31
4.6.2 Messaggio Ping 32
4.6.3 Messaggio Pong 32
4.6.4 Messaggio Error 33
5. MESSAGGI FACOLTATIVI 33
5.1 Messaggio Away 34
5.2 Messaggio Rehash 34
5.3 Messaggio Restart 34
5.4 Messaggio Summon 35
5.5 Messaggio Users 35
5.6 Messaggio Operwall 36
5.7 Messaggio Userhost 37
5.8 Messaggio ISon 37
6. RISPOSTE 38
6.1 Risposte Error 38
6.2 Replica Command 41
6.3 Risposte numeriche riservate 46
7. AUTENTICAZIONE DI CLIENT E SERVER 46
8. DETTAGLI SULLE ATTUALI IMPLEMENTAZIONI 47
8.1 Protocollo di rete: TCP 47
8.1.1 Supporto per Unix sockets 47
8.2 Analisi dei comandi 47
8.3 Invio del messaggio 48
8.4 Connessione 'Liveness' 48
8.5 Effettuazione di una connessione server-client 48
8.6 Effettuazione di una connessione server-server 49
8.6.1 Scambio di informazioni di stato alla connessione 49
8.7 Chiusura della connessione server-client 49
8.8 Chiusura della connessione server-server 50
8.9 Tracciamento dei cambi di nickname 50
8.10 Controllo del flood dei clients 50
8.11 Ricerche anti-blocco 51
8.11.1 Ricerca dell' Hostname (DNS) 51
8.11.2 Ricerca dell' Username (Ident) 51
8.12 File di configurazione 51
8.12.1 Autorizzazione dei clients alla connessione 52
8.12.2 Operatori 52
8.12.3 Autorizzazione dei servers alla connessione 52
8.12.4 Informazioni accessorie sugli Amministratori del server 53
8.13 Partecipazione ai Canali 53
9. PROBLEMI CORRENTI 53
9.1 Adattamento a situazioni di dimensioni rilevanti 53
9.2 Etichette 53
9.2.1 Nicknames 53
9.2.2 Canali 54
9.2.3 Servers 54
9.3 Algoritmi 54
10. SUPPORTO E DISPONIBILITA' 54
11. CONSIDERAZIONI SULLA SICUREZZA 55
12. INDIRIZZI DEGLI AUTORI 55
1. INTRODUZIONE
Il protocollo IRC (Internet Relay Chat) e' 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 e' stato sviluppato su un sistema che usa il protocollo di rete TCP/IP,
senza nessuna necessita', tuttavia, che questa rimanga il suo solo ambito di utilizzo.
L'IRC stesso e' un sistema di teleconferenza che (mediante l'uso del modello client-server)
e' 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
clients (o altri server) possono connettersi, realizzando i necessari invio e distribuzione
contemporanea su piu' utenti del messaggio ed altre funzioni.
1.1 I Servers
Il server forma la spina dorsale di IRC, fornendo un punto al quale i
clients possono connettersi per parlarsi gli uni con gli altri, ed un punto di connessione
per altri server, formando cosi' una rete IRC. L'unica configurazione di rete permessa ai
servers di IRC e' 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 servers IRC]
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 clients 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 servers 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 e' connesso.
1.2.1 Gli Operatori
Per far si' che il lavoro di rete venga svolto in maniera sufficientemente ordinata, si
permette ad una determinata classe di clients (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
capacita' di compiere quelle operazioni. Si vedano le sezioni 4.1.7 (Messaggio Server Quit)
e 4.3.5 (Messaggio Connect).
Uno dei piu' controversi, tra i poteri attribuiti agli operatori e' la possibilita' 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 e' cosa critica, dal momento che un abuso di questa possibilita' risulta sempre
fastidioso e distruttivo. Per altri dettagli sul' argomento si veda la sezione 4.6.1
(Messaggio KILL).
1.3 I Canali
Un canale e' un gruppo, dotato di nome, di uno o piu' clients dove tutti i membri del gruppo
ricevono i messaggi indirizzati a quel canale. Il canale e' 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 puo' 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 necessita' che il primo carattere sia
"&" oppure "#", l'unica restrizione che sussiste per il nome del
canale e' che non contenga alcuno spazio (" "), un control G (^G o ASCII 7), o una
virgola ("," la quale e' considerata dal protocollo come separatore tra gli
elementi di una lista).
Ci sono due tipi di canali ammessi da questo protocollo. Uno e' un canale assegnato che e'
conosciuto da tutti i servers 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 e' preceduto da un carattere & e che) si distinguono per essere accessibili solo ai
clients del server ove il canale esiste. [Qui probabilmente il testo originale a nostra
disposizione omette parte del periodo, ma, dal contesto, si puo' tentare una interpretazione
che abbiamo inserito tra parentesi tonde. - Nota del revisore] 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 gia' 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 gia' 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 verra' accolta solo se si e' stati invitati da qualcuno. Secondo il protocollo, un
utente puo' 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 clients che sono connessi al server sul
rispettivo versante dello split, cessando di farne parte su quello opposto allo split.
Quando il collegamento e' ripristinato, i servers, di nuovo connessi, si comunicano l'un
l'altro la propria lista dei clients presenti sul canale i "modes" di quel canale.
Se il canale esiste su tutti e due i versanti i JOINs e i MODEs vengono interpretati in una
maniera inclusiva cosicche' i due versanti della nuova connessione si troveranno in accordo
su quali clients sono nel canale e qual' e' l' assetto dei modes del canale.
1.3.1 Gli Operatori di canale
L' operatore di canale (detto anche "chop" o "chanop") su un dato canale
puo' 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 e'
identificato dal simbolo '@' posto a fianco del suo nickname ogniqualvolta esso e' associato
con un canale (per esempio risponde ai comandi NAMES, WHO e WHOIS).
2. SPECIFICHE IRC
2.1 Generalita'
Il protocollo qui descritto realizza sia connessioni server-server che connessioni
client-server. Va detto, comunque, che ci sono piu' restrizioni nelle connessioni
client-server (che sono considerate inattendibili) che in quelle server-server.
2.2 Codici dei caratteri
Nessun set particolare di caratteri e' specificato. Il protocollo e' basato su un sistema di
codici composti da otto (8) bits, vale a dire un ottetto (byte). Ogni messaggio puo' 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.
2.3 Messaggi
I servers e i clients 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 e' consigliabile che
attende la replica del server per un tempo illimitato, poiche' le comunicazioni
client-server e server-server sono di natura essenzialmente asincrona.
Ogni messaggio IRC puo' essere consistere fondamentalmente di tre parti: il prefisso
(facoltativo), il comando, ed i parametri del comando (ce ne possono essere fino a 15). Il
prefisso, il comando e tutti i parametri sono separati da uno (o piu') caratteri
"spazio" (ASCII: 0x20).
La presenza di un prefisso e' 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 e' usato dai servers per specificare la vera origine del
messaggio. Se manca il prefisso, si assume che il messaggio abbia avuto origine dalla
connessione sulla quale e' stato ricevuto. Non e' necessario che un client premetta un
prefisso quando inviano un messaggio: se usano un prefisso, l'unico prefisso valido e' il
nickname registrato ed associato con quel client. Se la sorgente identificata dal prefisso
non puo' essere trovata nel database interno del server, oppure se la sorgente e' 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. Percio' il massimo numero di caratteri permesso
per ogni riga di comando con gli eventuali parametri e' di 510. Non c' e' la possibilita' di
usare linee di continuazione per i messaggi. Si veda la sezione 7 per maggiori informazioni
sulle implementazioni correnti.
2.3.1 Formato dei messaggi in 'pseudo' 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 e' scomposto ed analizzato nei componenti: (prefisso), (comando) e
lista di parametri uniti fra loro da componenti <intermedi> o <iniziali>.
Per tanto la rappresentazione BNF [Backus Normal Form - Nota del Revisore] di questo assetto
e':
<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 puo' 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> e'
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
e' solo un fatto dipendente dalla modalita' 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 pro' delle difficolta' nel normale trattamento
delle stringhe in linguaggio "C". Questo e' l' unico motivo per
cui non e' permesso l'uso del carattere NUL all' interno dei
messaggi.
5) - L'ultimo parametro puo' essere una stringa vuota.
6) - L'uso del prefisso esteso (['!' <user> ] ['@' <host> ])
non deve essere usato nelle comunicazioni server-server, ed e'
previsto solo nell' ambito della comunicazione server- client in modo da
fornire ai client maggiori informazioni utili riguardo la provenienza
del messaggio, senza necessita' 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 servers assumono che il primo parametro dopo il comando e' una
lista di obbiettivi, cosi' 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)>
2.4 Risposte numeriche
La maggior parte dei messaggi inviati al server generano una risposta di qualche sorta. La
risposta piu' frequente e' 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 e' 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 e' simile ad un normale messaggio, con la sola differenza che la parola-chiave e'
formata da tre cifre numeriche invece che da una stringa di lettere. Una lista delle
possibili risposte e' contenuta nella sezione 6.
3. CONCETTI DI IRC
Questa sezione e' 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]
3.1 Comunicazione uno a uno
La comunicazione uno a uno e' realizzata di solito dai clients, dal momento che la maggior
parte del traffico server a server non e' il risultato di servers che parlino esclusivamente
tra loro. Per dare ai clients la possibilita' di parlare loro, e' necessario che tutti i
servers 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 e' quello piu' corto tra due punti qualsiasi della struttura.
Gli esempi che seguono fanno riferimento alla Figura 2.
Esempio 1:
Un messaggio tra i clients 1 e 2 e' visto solo dal server A, il quale lo invia direttamente
al client 2.
Esempio 2:
Un messaggio tra i clients 1 e 3 e' visto dai servers A e B, e dal client 3. A nessun altro
server o client e' permesso di vedere il messaggio.
Esempio 3:
Un messaggio tra i clients 2 e 4 e' visto dai servers A, B, C e D, e solamente dal client 4.
3.2 Uno a molti
Lo scopo principale di IRC e' di realizzare un luogo pubblico di incontro nell' ambito del
quale sia possibile, in maniera semplice ed efficiente, lo scambio di messaggi fra piu'
persone (conversazione uno a molti). A questo proposito IRC offre diversi mezzi, ognuno dei
quali e' orientato al raggiungimento di uno specifico scopo.
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 e' 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 e' 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.
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 e' 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 e' inviata solo a
quei servers cui siano collegati utenti di un canale dato. Se ci sono piu' utenti sullo
stesso server per lo stesso canale, il messaggio e' inoltrato solamente una volta a quel
server e poi inviato ad ognuno dei clients del canale. Questa operazione viene poi ripetuta
per ogni combinazione client-server finche' 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 clients in un canale. Tutti i messaggi attraversano un percorso come se fossero messaggi
privati tra i due clients a prescindere dal canale.
Esempio 6:
Clients 1, 2 e 3 dentro un canale. Tutti i messaggi al canale sono inviati a tutti i clients
e solo a quei servers 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.
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.
3.3 Uno a tutti
Il tipo di messaggio uno a tutti e' meglio denotato come un messaggio diffuso, inviato a
tutti i clients o/e a tutti i servers. In una rete di servers e utenti di grandi dimensioni,
un messaggio singolo puo' 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' e' altra soluzione che diffonderli a tutti i servers, affinche'
le informazioni di stato contenute da ogni server siano ragionevolmente coerenti tra i
servers stessi.
3.3.1 Client a Client
Non c' e' alcuna categoria di messaggi per la quale, partendo da un messaggio singolo,
derivi un messaggio che sia inviato ad ogni altro client.
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.
3.3.3 Server a Server.
Se la maggior parte dei messaggi tra due servers viene distribuita a tutti gli
"altri" server, questo e' 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 totalita' dei messaggi originati da un server vengono
distribuiti a tutti gli altri servers connessi.
4. INFORMAZIONI DETTAGLIATE SUI SINGOLI MESSAGGI
Nelle pagine seguenti vengono descritti tutti i messaggi riconosciuti da un server e da un
client IRC. Tutti i comandi descritti in questa sezione devono essere implementati su ogni
server per questo protocollo.
Quando viene data la risposta ERR_NOSUCHSERVER, significa che non e' stato possibile trovare
il parametro <server>. Il server non deve dare ulteriori risposte per questo comando.
Il server, al quale un client e' connesso, deve analizzare il messaggio completo, reinviando
al mittente ogni eventuale errore. Se il server si imbatte in un errore fatale durante l'
analisi di un messaggio, un messaggio di errore deve essere inviato al mittente e l'analisi
deve essere interrotta. Possono essere considerati errori fatali: un comando non corretto,
una destinazione che risulta in qualche modo sconosciuta al server (server, nick, nome del
canale rientrano in questa categoria), un numero insufficiente di parametri oppure un
privilegio non corretto.
Se viene presentato un set completo di parametri, allora di ognuno di essi deve essere
controllata la validita', ed eventuali risposte appropriate deve inviate al client. Nel caso
di un messaggio che usi la virgola come separatore dei parametri, una risposta deve essere
mandata per ogni voce.
Negli esempi sotto elencati, alcuni messaggi usano il formato completo previsto:
:Name COMMAND parameter list
Un tale esempio rappresenta un
messaggio proveniente da "Name" in transito tra due servers, dove e' essenziale
includere il nome del mittente originario del messaggio, cosi' che i servers remoti possano
mandare una risposta attraverso il percorso corretto.
4.1 Registrazione di Connessione.
I comandi qui descritti sono usati per registrare una connessione con un server IRC, sia
come utente che come server, e per sconnettersi in maniera corretta.
Non e' necessario un comando "PASS" perche' la connessione di un utente o di un
server sia registrata, ma, nel caso ci fosse, esso deve precedere il messaggio del server
oppure l' ultimo degli elementi della combinazione NICK/USER. E' fortemente raccomandato che
tutte le connessioni al server abbiano una password in modo da dare un certo livello di
sicurezza alle connessioni attuali. L'ordine raccomandato dei comandi da inviare per la
registrazione di un client e' il seguente:
1. messaggio Pass
2. messaggio Nick
3. messaggio User
4.1.1 Messaggio Password
Comando: PASS
Parametri: <password>
Il comando PASS e' usato per
stabilire una parola d' ordine per la connessione. La
parola d' ordine puo' e deve essere stabilita prima che sia fatto qualsiasi tentativo di
registrare la connessione presso il server. Normalmente questo richiede che il client invii
un comando PASS prima di inviare la combinazione NICK/USER ed il server *deve* inviare un
comando PASS prima di ogni comando SERVER. La password fornita deve essere uguale a quella
contenuta nelle righe C/N (per i servers) o nelle righe I (per i clients). E' possibile
inviare comandi PASS multipli prima di registrarsi, ma solamente l'ultimo comando inviato
viene usato per la verifica della parola e non puo' essere cambiato una volta registrato.
Risposte numeriche:
ERR_NEEDMOREPARAMS (Errore_necessitano piu' parametri)
ERR_ALREADYREGISTRED (Errore_gia' registrato)
Esempio:
PASS parola_d_ordine_qui
4.1.2 Messaggio Nickname
Comando: NICK
Parametri: <nickname> [ <hopcount> ]
Il messaggio NICK e' usato per
dare un nickname ad un utente o per cambiare quello che aveva in precedenza. Il parametro
<hopcount> e' usato solamente dai servers per indicare quanto disti un nick dal suo
server originario. Una connessione locale ha un hopcount di 0. Se l' hopcount viene fornito
da un client, deve essere ignorato.
Se un messaggio NICK arriva ad un server che e' gia' a conoscenza di un identico nickname
per un altro client, si verifica una collisione di nicknames. Il risultato di una collisione
di nicknames e' la rimozione, dal database del server, di tutte le presenze del nickname, e
un comando KILL viene emesso per rimuovere il nickname da tutti i database degli altri
servers. Se il messaggio NICK, causa della collisione, era un cambio di nickname, allora
anche il nick originale (quello vecchio) deve essere rimosso.
Se il server riceve un NICK gia' presente da un client che e' connesso direttamente, puo'
inviare al client locale un messaggio di ERR_NICKCOLLISION, ignorare il comando NICK, e non
generare alcun kill.
Risposte Numeriche:
ERR_NONICKNAMEGIVEN (Errore_non e' stato dato nessun nickname)
ERR_ERRONEUSNICKNAME (Errore_nickname errato)
ERR_NICKNAMEINUSE (Errore_nickname gia' in uso)
ERR_NICKCOLLISION (Errore_collisone di nicknames)
Esempio:
NICK Wiz ; Inserimento nuovo nick "Wiz".
:WiZ NICK Kilroy ; WiZ cambia il suo nickname in Kilroy.
4.1.3 Messaggio User, utente
Comando: USER
Parametri: <nome_utente> <nome_macchina> <nome_server> <nome_reale>
Il messaggio USER e' usato, all'inizio di una
connessione, per specificare il nome dell'utente, della macchina dell' utente, del server ed
il vero nome del nuovo utente. E' usato, inoltre, nelle comunicazioni tra servers, per
indicare un nuovo utente in arrivo su IRC dal momento che un utente e' registrato solamente
dopo che i comandi USER e NICK sono stati ricevuti da un client.
Tra i servers il comando USER deve essere preceduto dal NICKname del client. Notare che il
nome dell'host e del server sono normalmente ignorati dal server IRC quando il comando USER
arriva da un utente connesso direttamente (per ragioni di sicurezza), ma sono usati nelle
comunicazioni server-server. Questo significa che un comando NICK deve sempre essere inviato
ad un server remoto quando un nuovo utente viene presentato al resto della rete, prima che
il relativo comando USER sia inviato.
Bisogna prestare attenzione al fatto che il parametro nome_reale deve essere l'ultimo,
perche' puo' contenere dei caratteri spazio, e deve essere preceduto dal carattere due punti
(':') per far si' che sia riconosciuto.
Dal momento che per l'utente e' facile mentire sul suo nome-utente facendo affidamento
unicamente sul messaggio USER, e' raccomandato l'uso di un "Identity Server". Se
la macchina dalla quale un utente si connette ha un server in grado di esplicare questa
funzione, il nome_utente adottato sara' quello proveniente dalla risposta dell'
"Identity Server".
Risposte numeriche:
ERR_NEEDMOREPARAMS (Errore_necessitano piu' parametri)
ERR_ALREADYREGISTRED (Errore_gia' registrato)
Esempi:
USER guest tolmoon tolsun :Ronnie Reagan ; Utente che registra se stesso
con l'username "guest" ed il vero nome "Ronnie Reagan".
:testnick USER guest tolmoon tolsun :Ronnie Reagan ;messaggio tra servers
con il nickname al quale appartiene il comando USER.
4.1.4 Messaggio Server
Comando: SERVER
Parametri: <nome_server> <numero_tratte> <info>
Il messaggio server viene utilizzato per
comunicare ad un server che dall'altra parte di una nuova connessione c' e' un server.
Questo messaggio viene anche usato per passare i dati del server a tutta la rete. Quando un
nuovo server e' connesso alla rete, le informazioni che lo riguardano sono inviate a tutto
il network. <numero-tratte> viene usato per dare a tutti i servers alcune informazioni
interne sulla distanza cui si trova ciascun server. Con una lista completa dei servers,
sarebbe possibile ricostruire una mappa completa della configurazione dei collegamenti fra i
servers, ma l' hostmask ne impedisce la realizzazione.
Il messaggio SERVER deve essere accettato solamente: (a) o da una connessione non ancora
registrata e sta cercando di registrarsi come server; (b) o da una connessione gia'
esistente con un altro server, nel qual caso il messaggio SERVER introduce un nuovo server
che si trova dietro quel server.
La maggior parte degli errori che si verificano con la ricezione di un comando SERVER
consistono in una interruzione della connessione da parte del server di destinazione (target
SERVER). Di solito le risposte di errore sono inviate usando il comando ERROR, piuttosto che
inviare quelle numeriche, dal momento che il comando ERROR ha diverse proprieta' utili che
lo rendono, in questo caso, vantaggioso.
Se un messaggio SERVER viene analizzato e cerca di introdurre un server che e' gia' noto al
server ricevente, la connessione dalla quale arriva il messaggio deve essere chiusa (se si
seguono le procedure corrette), in quanto si e' formato un doppio percorso per quel server e
la natura aciclica della rete IRC risulta compromessa.
Risposta Numerica:
ERR_ALREADYREGISTRED (Errore_gia' registrato)
Esempi:
SERVER test.oulu.fi 1 :[tolsun.oulu.fi] Experimental server ;
Il nuovo server test.oulu.fi si introduce e cerca di registrarsi.
Il nome tra parentesi [..] e' il nome della macchina sulla quale
e' attivo test.oulu.fi.
:tolsun.oulu.fi SERVER csd.bu.edu 5 :BU Central Server
;Il server tolsun.oulu.fi e' il nostro collegamento per
csd.bu.edu che si trova a 5 tratte di distanza.
4.1.5 Messaggio Oper, Operatore
Comando: OPER
Parametri: <utente> <parola_d_ordine>
Il messaggio OPER e' usato da un utente normale
per ottenere i privilegi di operatore. La combinazione di <utente> e
<parola_d_ordine> e' richiesta per avere quei privilegi.
Se il client che invia il comando OPER fornisce la corretta parola d' ordine per l' utente
dato, il server informa del nuovo operatore il resto della rete effettuando un "MODE
+o" per il nickname del client.
Il messaggio OPER e' solamente un messaggio client-server.
Risposte numeriche:
ERR_NEEDMOREPARAMS (Errore_necessitano piu' parametri)
RPL_YOUREOPER (risposta_sei gia' operatore)
ERR_NOOPERHOST (errore_non ci sono O: line per l'utente spec.)
ERR_PASSWDMISMATCH (errore_la password non corrisponde)
Esempio:
OPER foo bar ; Tentativo di registrare come un operatore usando
"foo" come nome utente e "bar" come parola d' ordine.
4.1.6 Messaggio Quit (abbandonare)
Comando: QUIT
Parametri: [<Messaggio di cessazione>]
La sessione di un client e' terminata con un
messaggio di cessazione. Il server deve chiudere la connessione con un client che invia un
messaggio QUIT. Se viene dato un "Messaggio di cessazione", verra' mostrato questo
al posto del messaggio di default, consistente nel semplice nickname.
Quando un tratto della rete si interrompe (sconnessione di due server) "split", il
messaggio quit si compone dei nomi dei due servers coinvolti separati da uno spazio. Il
primo nome e' quello del server che e' ancora connesso, il secondo quello del server
sconnesso.
Se, per qualche altra ragione, la connessione con un client viene chiusa senza che il client
abbia inviato un messaggio QUIT (per esempio il client si pianta e si verifica un EOF (End
Of File) sul socket) (4), il server deve compilare il messaggio di abbandono con una
formulazione che rifletta la natura dell'evento che ha causato la sconnessione.
Risposte Numeriche:
Nessuna.
Esempio:
QUIT :Gone to have lunch; Format preferibile del messaggio.
4.1.7 Messaggio Server Quit
Comando: SQUIT
Parametri: <server> <commento>
Il messaggio SQUIT viene impiegato per rendere
conto dei servers che abbandonano oppure che smettono di funzionare. Se un server desidera
interrompere la connessione con un altro server deve mandare un messaggio SQUIT all'altro
server usando il nome dell' altro server, che chiude la sua connessione col server che
abbandona, come parametro "server".
La disponibilita' di questo comando agli operatori anche per mantenere ordinato, l' assetto
delle connessioni all' interno della rete IRC. Gli operatori possono dunque usare il
messaggio SQUIT per una connessione ad un server remoto. In questo caso lo SQUIT deve essere
analizzato da ogni server tra l'operatore ed il server remoto, aggiornando la
"visione" della rete che ciascun server deve conservare, come viene spiegato piu'
sotto.
Il parametro "commento" dovrebbe essere fornito da tutti gli operatori che
eseguono uno SQUIT su un server remoto (che non e' connesso cioe' al server sul quale essi
operano) cosicche' gli altri operatori siano informati sui motivi del provvedimento. Il
"commento" viene definito anche dai server, che possono formularlo come un
messaggio di errore o simili.
Ambedue i servers che si trovino agli estremi della connessione che viene chiusa devono
inviare un messaggio SQUIT (a tutte le altre connessioni server che li riguardano) per tutti
gli altri servers che sono considerati trovarsi a valle di ciascuno di questi collegamenti.
Alla stessa maniera, un messaggio QUIT deve essere inviato a tutti gli altri servers
connessi al resto della rete nell'interesse di tutti i clients che si trovino a valle di
quel collegamento. In aggiunta a tutto questo, a tutti i membri di un canale, i quali
perdono un membro a causa dello split, deve essere inviato un messaggio QUIT.
Se la connessione ad un server viene terminata prematuramente (per esempio il server dalla
parte opposta del link smette di funzionare), al server che rileva questa sconnessione e'
richiesto di informare il resto della rete che la connessione si e' chiusa e di compilare il
campo "commento" con qualcosa di appropriato.
Risposte Numeriche:
ERR_NOPRIVILEGES (errore_non hai i privilegi dell'operatore)
ERR_NOSUCHSERVER (errore_ il serve indicato non esiste)
Esempi:
SQUIT tolsun.oulu.fi :Bad Link ?;
la connessione al server tolson.oulu.fi e' stata terminata
a causa di un "Bad Link" (cattiva connessione).
:Trillian SQUIT cm22.eng.umd.edu :Server out of control ; messaggio da
Trillian per disconnettere "cm22.eng.umd.edu" dalla rete
perche' "Server out of control" (server fuori controllo).
4.2 Operazioni del Canale
Questo gruppo di messaggi concerne la manipolazione dei canali, le loro proprieta' (mode del
canale), ed il loro contenuto (usualmente clients). Per una giusta realizzazione, e'
necessario stabilire un numero di regole, quando i clients che si trovano agli estremi
opposti della rete inviano messaggi che potrebbero collidere fra loro. E' richiesto,
inoltre, che i servers mantengano una traccia storica dei nicknames per assicurarsi che,
ogniqualvolta un parametro <nick> e' dato, il server ne controlli la storia nel caso
sia stato cambiato di recente.
4.2.1 Messaggio Join
Comando: JOIN
Parametri: <canale>{,<canale>} [<chiave>{,<chiave>}]
Il comando JOIN e' usato dal client per avere
accesso ai messaggi provenienti da un dato canale. La verifica della sussistenza della
condizione perche' un client sia autorizzato o meno ad aggregarsi al canale, viene
realizzata dal server al quale il client e' connesso. Tutti gli altri servers aggiungono
automaticamente il client al canale quando la sua ammissione ad un canale e' notificata da
altri servers. Le condizioni che determinano l' ammissione sono le seguenti:
1. Il client deve essere invitato se il canale e' ad invito
(mode +i);
2. Il nick/nome_utente/nome_macchina del client non devono
corrispondere a ban attivi;
3. se e' definita una parola d' ordine di acceso, deve essere
fornita la parola corretta (mode +k) (5).
Tutto questo e' discusso piu' dettagliatamente
nella sezione Comando MODE (si veda la sezione 4.2.3 per maggiori informazioni).
Una volta che gli utenti si sono aggregati al canale, essi ricevono notizia di tutti i
comandi, ricevuti dal loro server, che riguardano il canale. Questo Include MODE, KICK,
PART, QUIT e naturalmente PRIVMSG/NOTICE. Il comando JOIN necessita di essere trasmesso a
tutti i servers di modo che ogni server sappia dove trovare gli utenti che sono sul canale.
Questo permette una ottimizzazione nell' invio dei messaggi di tipo PRIVMSG/NOTICE al
canale.
Se un JOIN ha successo, all'utente vengono notificati l' "argomento" del canale
(topic) - usando RPL_TOPIC - e la lista degli utenti che sono nel canale, che include
l'utente aggregato, (usando RPL_NAMREPLY).
Risposte Numeriche:
ERR_NEEDMOREPARAMS (errore_necessitano piu' parametri)
ERR_BANNEDFROMCHAN (errore_bannato dal canale)
ERR_INVITEONLYCHAN (errore_canale ad invito)
ERR_BADCHANNELKEY (errore_key sbagliata)
ERR_CHANNELISFULL (errore_canale pieno)
ERR_BADCHANMASK (errore_Chanmask errata)
ERR_NOSUCHCHANNEL (errore_canale inesistente)
ERR_TOOMANYCHANNELS (errore_troppi canali)
RPL_TOPIC (risposta_topic del canale: ) (6)
Esempi:
JOIN #foobar ; richiesta di aggregazione al canale
#foobar.
JOIN &foo fubar ; richiesta di aggregazione al canale
&foo usando la parola d' ordine "fubar".
JOIN #foo,&bar fubar ; richiesta di aggregazione al canale #foo
usando la parola d'ordine "fubar" ed al
canale &bar usando nessuna key.
JOIN #foo,#bar fubar,foobar ; richiesta di aggregazione al canale #foo
usando la parola d' ordine "fubar" ed al
canale #bar usando "foobar".
JOIN #foo,#bar ; richiesta di aggregazione ai canali #foo
e #bar.
:WiZ JOIN #Twilight_zone ; messaggio JOIN da WiZ
4.2.2 Messaggio Part
Comando: PART
Parametri: <canale>{,<canale>}
Il messaggio PART comporta la rimozione del
client mittente del messaggio dalla lista di utenti attivi di tutti i canali elencati nella
riga dei parametri.
Risposte Numeriche:
ERR_NEEDMOREPARAMS (errore_necessitano piu' parametri)
ERR_NOSUCHCHANNEL (errore_canale inesistente)
ERR_NOTONCHANNEL (errore_non sei sul canale)
Esempi:
PART #twilight_zone ; richiesta di lasciare il canale "#twilight_zone"
PART #oz-ops,&group5 ; richiesta di lasciare sia il canale "&group5"
che "#oz-ops".
4.2.3 Messaggio Mode
Comando: MODE
Il comando MODE ha due scopi: permette infatti di cambiare i modes sia dei canali che degli
utenti. La ragione di questa scelta e' che in futuro i nicknames saranno obsoleti e l'
entita' equivalente sara' il canale. (7)
Quando viene analizzato un comando MODE, e' essenziale che prima il messaggio venga
analizzato nella sua totalita' e che, in un secondo tempo, i cambiamenti dettati dal
messaggio vengano effettuati.
4.2.3.1 Mode dei canali
Parametri: <canale> {[+|-]|o|p|s|i|t|n|b|v} [<limite>] [<utente>]
[<schema_di_ban>] (8)
Il comando MODE e' a disposizione degli
operatori di canale perche' possano cambiare le caratteristiche del `loro' canale. E'
richiesto inoltre che i servers siano in grado di cambiare i mode dei canali cosi' che sia
possibile creare operatori.
I mode dei canali disponibili sono i seguenti:
o - da'/toglie i privilegi di operatore;
p - permette di definire il canale come privato;
s - permette di definire il canale come segreto;
i - permette di definire il canale come canale ad invito;
t - permette di definire il topic come definibile solo da operatori
del canale;
n - permette di stabilire la proibizione di invio di messaggi da
clients che sono al di fuori del canale;
m - permette di definire il canale come canale moderato;
l - stabilisce un limite al numero di utenti presenti sul canale;
b - definisce uno schema di ban per tenere gli utenti fuori del
canale;
v - da'/toglie la possibilita' di parlare su un canale moderato
k - setta una parola d' ordine per l' acceso al canale.
Quando si usano le opzioni 'o' e 'b', e' stata
imposta una restrizione di tre comandi per mode. Vale a dire, ogni combinazione di 'o' e
(Qui il testo inglese e' lacunoso, ma, con ogni probabilita' si intende dire che ogni
combinazione di 'o' e 'b', puo' contenere al massimo tre elementi. - N.d.T.)
4.2.3.2 Mode dell'utente
Parametri: <nickname> {[+|-]|i|w|s|o} (9)
I MODEs degli utenti sono cambiamenti che
determinano come il client e' visto dagli altri, oppure che tipo di messaggi 'extra' possono
essere inviati al client. Il comando MODE per l' utente puo' essere accettato solamente se
il mittente del messaggio e il nickname dato come parametro sono identici.
I mode disponibili sono i seguenti:
i - definisce un utente come invisibile;
s - determina la ricezione da parte dell' utente delle notizie del
server;
w - permette all'utente di ricevere i wallops (messaggi tra
operatori);
o - permette di definire l' utente come operatore.
Mode in aggiunta a questi potranno essere
disponibili prossimamente.
Se un utente cerca di farsi operatore da solo, usando il mode "+o", il tentativo
e' ignorato. Non c' e' alcuna restrizione, comunque, per chiunque voglia deopparsi (usando
"-o").
Risposte Numeriche:
ERR_NEEDMOREPARAMS (errore_necessitano piu' parametri)
RPL_CHANNELMODEIS (risposta_il modo di canale e': )
ERR_CHANOPRIVSNEEDED (errore_sono richiesti le prerogative di
operatore di canale)
ERR_NOSUCHNICK (errore_nick inesistente)
ERR_NOTONCHANNEL (errore_non sei sul canale)
ERR_KEYSET (errore_nella definizione della parola d' ordine)
RPL_BANLIST (risposta_lista dei ban: )
RPL_ENDOFBANLIST (risposta_fine della lista dei ban: )
ERR_UNKNOWNMODE (errore_modo sconosciuto)
ERR_NOSUCHCHANNEL (errore_canale non esistente)
ERR_USERSDONTMATCH (errore_user non corrispondente)
RPL_UMODEIS (risposta_il mode dell' utente e': )
ERR_UMODEUNKNOWNFLAG (errore_flag sconosciuto per un mode utente)
Esempi:
Uso dei MODE del canale:
MODE #Finnish +im ; rende il canale #Finnish moderato e ad invito.
MODE #Finnish +o Kilroy ; da i privilegi di operatore di canale a Kilroy
sul canale #Finnish.
MODE #Finnish +v Wiz ; permette a WiZ di parlare in #Finnish.
MODE #Fins -s ; rende il canale #Fins non piu' segreto.
MODE #42 +k oulu ; definisce "oulu" come parola d' ordine per
l' accesso al canale.
MODE #eu-ofors +l 10 ; setta a 10 il numero limite di utenti presenti
sul canale.
MODE &oulu +b ; lista gli schemi di ban definiti per il canale.
MODE &oulu +b *!*@* ; impedisce l' accesso al canale di tutti gli
utenti.
MODE &oulu +b *!*@*.edu ; impedisce l'accesso al canale di ogni utente il
cui nome di macchina corrisponda ad *.edu.
Uso dei MODE dell'utente:
MODE WiZ -w ; disabilita WIZ dalla ricezione dei wallops.
Angel MODE Angel +i ; messaggio da Angel di rendersi invisibile.
MODE WiZ -o ; WiZ si deoppa (rimuovendo lo status di
operatore). Il contrario ovvio di questo
comando non deve essere permesso agli utenti
dal momento che aggirerebbe il comando OPER.
4.2.4 Messaggio Topic
Comando: TOPIC
Parametri: <canale> [<topic>]
Il messaggio TOPIC e' usato per cambiare o
prender visione del topic di un canale. Se non e' dato alcun parametro <topic> il
messaggio di ritorno sara' il topic del canale. Se invece il parametro <topic> e'
presente, il topic di quel canale potra' essere cambiato, se il mode del canale permette
questa azione
Risposte Numeriche:
ERR_NEEDMOREPARAMS (errore_necessitano piu' parametri)
ERR_NOTONCHANNEL (errore_non sei sul canale)
RPL_NOTOPIC (risposta_topic vuoto)
RPL_TOPIC (risposta_il topic del canale e': )
ERR_CHANOPRIVSNEEDED (errore_necessitano i privilegi dell'operatore)
Esempi:
:Wiz TOPIC #test :New topic ; l'utente Wiz definisce il topic.
TOPIC #test :another topic ; definisce il topic su #test come
"another topic".
TOPIC #test ; controlla il topic del canale #test.
4.2.5 Messaggio Names
Comando: NAMES
Parametri: [<canale>{,< canale>}]
Usando il comando NAMES gli utenti possono
avere una lista di tutti i nicknames che siano loro visibili, su ogni canale che essi
vedono. I nomi dei canali che possono vedere sono quelli che non sono privati (+p) o segreti
(+s) o quelli sui quali si trovano. Il parametro <canale> specifica a proposito di
quale/i canale/i inviare l'informazione richiesta, se questa risulta valida. Non c' e'
risposta di errore in caso di nome errato del canale.
Se non e' dato alcun parametro <canale>, viene fornita una lista di tutti i canali e
dei loro occupanti. Alla fine della lista, viene fornito un elenco degli utenti (come
appartenenti ad un canale "*") che sono visibili, ma non su ogni canale o
invisibili su un canale visibile.
Risposte numeriche:
RPL_NAMREPLY (risposta_risposta dei nomi: )
RPL_ENDOFNAMES (risposta_fine dei nomi: )
Esempi:
NAMES #twilight_zone,#42 ; lista gli utenti visibili sui canali
#twilight_zone e #42 se i canali sono
visibili.
NAMES ; elenca tutti i canali ed utenti visibili.
4.2.6 Messaggio List
Comando: LIST
Parametri: [<canale>{,<canale>} [<server>]]
Il messaggio LIST e' usato per listare i canali
ed i loro topics. Se e' presente il parametro <canale>, viene mostrato solo lo status
di quel canale. I canali privati vengono listati (senza il loro topic) come "Prv"
a meno che il client da cui proviene la domanda di informazione, non sia su quel canale.
Alla stessa maniera, i canali segreti non vengono elencati, a meno che il client non sia un
membro del canale in questione.
Risposte Numeriche:
ERR_NOSUCHSERVER (errore_server inesistente)
RPL_LISTSTART (risposta_inizio della lista: )
RPL_LIST (risposta_lista: )
RPL_LISTEND (risposta_fine della lista: )
Esempi:
LIST ; lista tutti i canali.
LIST #twilight_zone,#42 ; lista i canali #twilight_zone e #42
4.2.7 Messaggio Invite
Comando: INVITE
Parametri: <nickname> <canale>
Il messaggio INVITE usato per invitare gli
utenti su un canale. Il parametro <nickname> e' il nick della persona da invitare sul
canale <canale>. Non e' necessario che il canale in cui <nickname> viene
invitato, debba esistere o debba essere un canale valido. Per invitare un utente in un
canale ad invito (MODE +i) si deve essere riconosciuti come operatori del canale.
Risposte Numeriche:
ERR_NEEDMOREPARAMS (errore_necessitano piu' parametri)
ERR_NOSUCHNICK (errore_nick inesistente)
ERR_NOTONCHANNEL (errore_non sei sul canale)
ERR_USERONCHANNEL (errore_utente gia' sul canale)
ERR_CHANOPRIVSNEEDED (errore_necessitano i privilegi dell'operatore)
RPL_INVITING (risposta_invito a: )
RPL_AWAY (rispoasta_utente in away: )
Esempi:
:Angel INVITE Wiz #Dust ; l'utente Angel invita WiZ sul canale
#Dust
INVITE Wiz #Twilight_Zone ; comando di invito di WiZ su
#Twilight_zone
4.2.8 Messaggio Kick
Comando: KICK
Parametri: <canale> <utente> [<commento>]
Il comando KICK puo' essere usato per rimuovere
forzatamente un utente da un canale. Esso lo 'scalcia fuori del canale' (PART forzato). Solo
un operatore di canale puo' rimuovere un utente dal canale. Ogni server che riceva un
messaggio KICK controlla se il comando sia valido (per esempio se il mittente e' un
operatore), prima di rimuovere la vittima dal canale.
Risposte Numeriche:
ERR_NEEDMOREPARAMS (errore_necessitano piu' parametri)
ERR_NOSUCHCHANNEL (errore_nick inesistente)
ERR_BADCHANMASK (errore_schema di nome di canale errato)
ERR_CHANOPRIVSNEEDED (errore_necessitano i privilegi dell'operatore)
ERR_NOTONCHANNEL (errore_non sei sul canale)
Esempi:
KICK &Melbourne Matthew ; caccia Matthew da &Melbourne
KICK #Finnish John :Speaking English ; caccia John from #Finnish
giustificando l' azione con"Speaking English" (commento)
:WiZ KICK #Finnish John ; messaggio di KICK da WiZ per
rimuovere John dal canale #Finnish
NOTA:
E' possibile estendere i parametri del comando KICK come segue:
<canale>{,<canale>} <utente>{,<utente>} [<commento>] (10)
4.3 Comandi e richieste di informazioni al server
Il gruppo di comandi per la richiesta di informazioni al server e' stato previsto per
ottenere informazioni su ogni server connesso alla rete. Tutti i servers connessi devono
replicare alle richieste di informazioni in maniera corretta. Ogni risposta non corretta (o
qualunque mancanza di risposta) deve essere considerata come un mal funzionamento da parte
del server che deve essere sconnesso e/o disabilitato prima possibile e finche' non si sia
posto rimedio alla disfunzione.
In quelle domande, dove compare un parametro "<server>", generalmente
significa che il parametro potrebbe essere un nickname o un server oppure un nome jolly di
qualche sorta. Per ogni parametro, comunque, vengono generati solamente una domanda ed un
set di risposte.
4.3.1 Messaggio Version
Comando: VERSION
Parametri: [<server>]
Il messaggio VERSION e' usato per avere
informazioni a proposito della versione del programma implementato sul server. Un parametro
facoltativo <server> viene usato per informarsi sulla versione del programma attivo su
un server al quale un client non sia connesso direttamente.
Risposte Numeriche:
ERR_NOSUCHSERVER (errore_server inesistente)
RPL_VERSION (risposta_La versione e': )
Esempi:
:Wiz VERSION *.se ; messaggio da Wiz per informarsi sulla versione
di un server il cui nome corrisponda allo
schema: "*.se"
VERSION tolsun.oulu.fi ; richiesta di informazione sulla versione del
server "tolsun.oulu.fi".
4.3.2 Messaggio Stats
Comando: STATS
Parametri: [<richiesta> [<server>]]
Il messaggio STATS usato per chiedere
informazioni statistiche su un determinato server. Se il parametro <server> viene
omesso, viene inviata solamente la risposta di fine del messaggio stats. Le modalita' di
esecuzione di questo comando dipendono fortemente dal server che risponde, tuttavia i
servers debbono essere in grado di fornire le informazioni descritte qui di seguito (o
qualcosa di analogo).
Una particolare richiesta puo' essere denotata da una singola lettera controllata dal solo
server di destinazione (se dato come parametro <server>), ed e' invece trasmessa,
ignorata ed inalterata, dai servers intermedi. Le richieste di informazioni che seguono,
sono quelle reperibili nell'attuale implementazione di IRC, e costituiscono una porzione
abbondante delle informazioni di setup per il server in questione. Malgrado queste richieste
possano essere soddisfatte con modalita' diverse da altre versioni, tutti i servers
dovrebbero essere in grado di fornire una risposta valida ad una richiesta STAT, una replica
cioe', conforme ai formati di risposta comunemente usati e coerente con lo scopo della
richiesta.
Le richieste usualmente soddisfatte sono:
c - ritorna una lista di servers ai quali il server puo' connettersi
o dai quali permette connessioni;
h - ritorna una lista di servers i quali sono considerati
forzatamente "foglie" (elementi periferici) nell' albero della
rete oppure ai quali e' permesso di agire come suoi punti nodali;
i - ritorna una lista di hosts provenendo dai quali il server
permette ad un client di connettersi;
k - ritorna una lista di combinazioni nome_utente/nome_macchina
bannati su quel server;
l - ritorna una lista delle connessioni del server, mostrando da
quanto tempo si e' stabilita ogni connessione, il traffico su
quella connessione in bytes e messaggi per ogni direzione;
m - ritorna una lista di comandi riconosciuti dal server ed il
conteggio del numero di volte in cui ogni comando e' stato usato,
se il conteggio e' un numero diverso da zero;
o - ritorna una lista di hosts provenendo dai quali normali clients
sono autorizzati a diventare operatori;
y - mostra Y (Class) linee del file di configurazione del server;
u - ritorna una riga che mostra da quanto tempo il server e'attivo.
(11)
Risposte Numeriche:
ERR_NOSUCHSERVER (errore_server inesistente)
RPL_STATSCLINE (risposta_ad una richiesta di tipo "c")
RPL_STATSHLINE (risposta_ad una richiesta di tipo "h")
RPL_STATSILINE (risposta_ad una richiesta di tipo "i")
RPL_STATSKLINE (risposta_ad una richiesta di tipo "k")
RPL_STATSLLINE (risposta_ad una richiesta di tipo "l")
RPL_STATSNLINE (risposta_ad una richiesta di tipo "n")
RPL_STATSOLINE (risposta_ad una richiesta di tipo "o")
RPL_STATSQLINE (risposta_ad una richiesta di tipo "q")
RPL_STATSLINKINFO (risposta_ad una richiesta di informazioni sullo
stato delle connessioni)
RPL_STATSUPTIME (risposta_ad una richiesta di tipo "u")
RPL_STATSCOMMANDS (risposta_ad una richiesta di tipo "m")
RPL_ENDOFSTATS (risposta_fine delle informazioni statistiche)
Esempi:
STATS m ; controlla le statistiche di utilizzo dei
comandi sul server al quale si e'connessi
:Wiz STATS c eff.org ; richiesta di WiZ per informazioni sulle linee
C/N al server eff.org
4.3.3 Messaggio Links
Comando: LINKS
Parametri: [[<server remoto>] <schema_server>]
Col comando LINKS, un utente puo' ottenere l'
elenco di tutti i servers conosciuti al server che risponde alla richiesta di informazione.
La lista di servers inviata deve essere compatibile con lo schema di nome del server fornito
nel secondo parametro, se non viene data alcuno schema, viene inviata la lista completa.
Se il parametro <server remoto> viene dato in aggiunta a <schema_server>, il
comando LINKS viene inoltrato al primo server il cui nome (sempre se esista) corrisponde a
quello contenuto in <server remoto>, e a quel server e' allora richiesto di rispondere
alla domanda.
Risposte Numeriche:
ERR_NOSUCHSERVER (errore_server inesistente)
RPL_LINKS (risposta_lista collegamenti)
RPL_ENDOFLINKS (risposta_fine delle lista collegamenti)
Esempi:
LINKS *.au ; lista tutti i servers con un nome
coerente con lo schema_server *.au;
:WiZ LINKS *.bu.edu *.edu ; messaggio LINKS da WiZ al primo server
il cui nome e' coerente con lo schema *.edu per una
lista di servers che soddisfano lo schema *.bu.edu.
4.3.4 Messaggio Time
Comando: TIME
Parametri: [<server>]
Il messaggio TIME viene usato per chiedere
l'ora locale relativa al server specificato. Se non viene dato un parametro server, il
server che tratta il comando deve rispondere alla domanda.
Risposte Numeriche:
ERR_NOSUCHSERVER (errore_server inesistente)
RPL_TIME (risposta_ora locale)
Esempi:
TIME tolsun.oulu.fi ; controlla l'orario sul server "tolson.oulu.fi"
Angel TIME *.au ; l'utente Angel controlla l'orario su un server
corrispondente allo schema "*.au"
4.3.5 Messaggio Connect
Comando: CONNECT
Parametri: <server_destinazione> [<porta> [<server remoto>]]
Il comando CONNECT puo' essere usato per
forzare un server a stabilire una nuova ed immediata connessione ad un altro server. CONNECT
e' un comando privilegiato ed e' disponibile solamente agli operatori IRC. Dato un server
remoto, allora il tentativo di connessione viene effettuato da quel server al
<server_destinazione> attraverso la porta <porta>. [Pur essendo il termine
inglese originale: "port" equivalente all' italiano "porto", si mantiene
qui l' erronea traduzione "port" entrata ormai nella tradizione
tecnico-informatica dell' italiano. - Nota del revisore]
Risposte Numeriche:
ERR_NOSUCHSERVER (errore_server inesistente)
ERR_NOPRIVILEGES (errore_non hai i privilegi
dell'operatore)
ERR_NEEDMOREPARAMS (errore_necessitano piu' parametri)
Esempi:
CONNECT tolsun.oulu.fi ;tentativo di connettere un
server a tolsun.oulu.fi
:WiZ CONNECT eff.org 6667 csd.bu.edu ;tentativo effettuato da WiZ di
far connettere i servers eff.org e csd.bu.edu
sulla porta 6667.
4.3.6 Messaggio Trace
Comando: TRACE
Parametri: [<server>]
Il comando TRACE e' impiegato per trovare il
percorso verso un server specificato. Ogni server che riceve e tratta questo messaggio, deve
comunicare al server mittente informazioni su se stesso, inviando una risposta e denotandosi
come un collegamento di passaggio. Si forma cosi' una catena di risposte, simile a quella
che si riceve usando il "traceroute". Dopo aver inviato la risposta, il server
deve mandare il messaggio TRACE al server successivo, finche' il server il cui nome e'
contenuto nel parametro <server> non viene raggiunto. Se viene omesso il parametro
<server>, e' previsto che il comando TRACE invii un messaggio al mittente, indicando
con quali servers il server corrente ha una connessione diretta.
Se la destinazione data da <server> e' un server effettivamente collegato, allora al
server di destinazione e' e' fatto obbligo di notificare tutti i servers e gli utenti
connessi, anche se, in effetti, solo agli operatori e' permesso vedere gli utenti presenti.
Se la destinazione data da <server> e' il nick di un utente, allora solo una risposta
per quel nick viene data. (12)
Risposte Numeriche:
ERR_NOSUCHSERVER (errore_server inesistente)
Se il messaggio TRACE e' indirizzato ad un
altro server, tutti i servers
intermedi devono inviare una risposta RPL_TRACELINK per indicare che il messaggio TRACE e'
passato attraverso di loro e specificare quale sara' la destinazione immediatamente
successiva.
RPL_TRACELINK (risposta_traccia di collegamento)
Una risposta TRACE puo' essere composta da un numero qualsiasi delle
seguenti risposte numeriche.
RPL_TRACECONNECTING (risposta_TRACE: collegamento)
RPL_TRACEHESHAKE (risposta_TRACE: riconoscimento
(handshaking))
RPL_TRACEUNKNOWN (risposta_TRACE: elemento sconosciuto)
RPL_TRACEOPERATOR (risposta_TRACE: operatore)
RPL_TRACEUSER (risposta_TRACE: utente)
RPL_TRACESERVER (risposta_TRACE: server)
RPL_TRACESERVICE (risposta_TRACE: servizio)
RPL_TRACENEWTYPE (risposta_TRACE: nuovo tipo)
RPL_TRACECLASS (risposta_TRACE: classe)
Esempi:
TRACE *.oulu.fi ;TRACE ad un server il cui nome e' coerente con
lo schema *.oulu.fi
:WiZ TRACE AngelDust ;TRACE emesso da WiZ per il nick AngelDust
4.3.7 Messaggio Admin
Comando: ADMIN
Parametri: [<server>]
Il messaggio ADMIN viene usato per trovare il
nome dell'amministratore di un dato server, oppure del server corrente se il parametro
<server> viene omesso. Ogni server deve avere la possibilita' di inoltrare messaggi
ADMIN ad altri servers.
Risposte Numeriche:
ERR_NOSUCHSERVER (errore_server inesistente)
RPL_ADMINME (risposta_ADMIN: me)
RPL_ADMINLOC1 (risposta_ADMIN: locale1)
RPL_ADMINLOC2 (risposta_ADMIN: locale2)
RPL_ADMINEMAIL (risposta_indirizzo e-mail dell' amministratore:)
Esempi:
ADMIN tolsun.oulu.fi ; richiesta di informazione ADMIN a
tolsun.oulu.fi
:WiZ ADMIN *.edu ; ADMIN richiesta da WiZ per il primo server il
cui nome e'coerente con lo schema *.edu.
4.3.8 Messaggio Info
Comando: INFO
Parametri: [<server>]
Il comando INFO provoca l' invio di una
risposta che descrive il server: la versione, data di compilazione, la release dell' ultimo
aggiornamento applicato (patchlevel), quando e' stato attivato, ed ogni altra informazione
che puo' essere considerata rilevante.
Risposte Numeriche:
ERR_NOSUCHSERVER (errore_server inesistente)
RPL_INFO (risposta_informazioni: )
RPL_ENDOFINFO (risposta_fine delle informazioni)
Esempi:
INFO csd.bu.edu ; richiesta di risposta INFO da csd.bu.edu
:Avalon INFO *.fi ; richiesta INFO da Avalon per il primo server il
cuoi nome e' coerente con lo schema *.fi.
INFO Angel ; richiesta INFO dal server al quale Angel
e' connesso.
4.4 Invio messaggi
Lo scopo principale del protocollo IRC e' di fornire una base comune per tutti i clients
sulla quale essi possano comunicare gli uni con gli altri. PRIVMSG e NOTICE sono gli unici
comandi a disposizione che di fatto inviano il testo di un messaggio da un client all'altro
- tutto il resto esiste per rendere possibile questa azione e per assicurare che l'invio
avvenga in modo strutturato ed affidabile.
4.4.1 Messaggi Privati
Comando: PRIVMSG
Parametri: <destinatario>{,<destinatario>} <testo da inviare>
PRIVMSG viene usato per inviare messaggi
privati tra utenti. <destinatario> e' il nickname del destinatario del messaggio.
<destinatario> puo' anche essere una lista di nomi o canali, separata da virgole.
Il parametro <destinatario> puo' anche essere uno schema di nome-macchina (#mask)
oppure uno schema di nome-server ($mask). In ambedue i casi il server inviera' il PRIVMSG a
coloro che hanno un server oppure una macchine il cui nome e' coerente con lo schema
fornito. Lo schema deve contenere almeno un (1) punto "." e nessun carattere-jolly
dopo l' ultimo punto ".". Questo e' necessario per prevenire qualcuno dall'
inviare messaggi del tipo "#*" o a "$*", che sarebbero trasmessi a tutti
gli utenti. L' esperienza insegna che di questo comando viene fatto si abusa spesso in
maniera irresponsabile. Per carattere-jolly si intendono i caratteri '*' e '?'. Questa
estensione al comando PRIVMSG e' disponibile solo per gli operatori.
Risposte Numeriche:
ERR_NORECIPIENT (errore_destinatario non specificato)
ERR_NOTEXTTOSEND (errore_testo non specificato)
ERR_CANNOTSENDTOCHAN (errore_invio impossibile al canale)
ERR_NOTOPLEVEL (errore_non livello massimo)
ERR_WILDTOPLEVEL (errore_livello massimo non giustificato)
ERR_TOOMANYTARGETS (errore_troppe destinazioni)
ERR_NOSUCHNICK (errore_nick inesistente)
RPL_AWAY (risposta_destinatario in away)
Esempi:
:Angel PRIVMSG Wiz :Hello are you receiving this message ?;
messaggio da Angel a Wiz.
PRIVMSG Angel :yes I'm receiving it !receiving it !'u>(768u+1n) .br;
messaggio a Angel.
PRIVMSG jto@tolsun.oulu.fi :Hello !;
messaggio ad un nome-utente "jto".
PRIVMSG $*.fi :Server tolsun.oulu.fi rebooting.;
messaggio a chiunque sia su un server con un
nome coerente con *.fi.
PRIVMSG #*.edu :NSFNet e' undergoing work, expect interruptions ;
messaggio a tutti gli utenti che hanno una
macchina il cui nome e' coerente con *.edu.
4.4.2 Messaggi Notice
Comando: NOTICE
Parametri: <nickname> <text>
Il messaggio NOTICE viene usato in modo simile
al PRIVMSG. La differenza tra NOTICE e PRIVMSG e' che una risposta automatica non deve mai
essere inviata come replica ad un messaggio NOTICE. Questa regola si applica pure ai servers
- essi non devono ritornare una risposta di errore al client, alla ricezione di un NOTICE.
Questa regola e' utile per impedire l' innescarsi di cicli senza uscita tra un client che
invia automaticamente qualcosa in risposta a qualcosa che ha ricevuto.
Di solito si adotta questo metodo con gli automi (clients che possiedono un modulo di
Intelligenza artificiale oppure un qualsiasi altro programma interattivo che controlla le
loro azioni), i quali inviano immancabilmente delle risposte, per paura che finiscano in
cicli senza fine con altri automi. [Si tratta dei cosi' detti bots - abbreviazione della
parola ceca "robot", programmi implementati sulla macchina di un client che
rimangono in linea ed hanno un comportamento del tutto automatico. - Nota del revisore]
Si veda PRIVMSG per maggiori dettagli sulle risposte e gli Esempi.
4.5 Richieste di informazioni sull'utente
Le richieste di informazioni sull'utente sono un gruppo di comandi che concernono
primariamente la ricerca di dettagli su un utente particolare oppure su un gruppo di utenti.
Quando si usano dei caratteri-jolly per denotare l' utente in questi comandi, di tutti gli
utenti che siano eventualmente coerenti con lo schema fornito, verranno inviate informazioni
solo sugli utenti "visibili" al richiedente. La visibilita' di un utente e'
determinata come una combinazione del mode dell'utente ed i comuni canali sui quali si
trovano sia l' utente inquisito che il richiedente.
4.5.1 Richiesta Who
Comando: WHO
Parametri: [<nome> [<o>]]
Il messaggio WHO e' usato da un client per
generare una richiesta la cui risposta e' una lista di informazioni su utenti che sono
coerenti con il parametro <nome> fornito dal client. In assenza del parametro
<nome>, tutti gli utenti visibili (utenti che non sono invisibili (modo-utente +i) e
che non hanno un canale in comune con il client richiedente) vengono listati . Lo stesso
risultato puo' essere raggiunto usando un <nome> "0" o qualsiasi schema con
caratteri-jolly con cui sarebbe coerente ogni possibile utente.
Il <nome> trasmesso a WHO viene confrontato col nome della macchina dell'utente, il
server, il "nome reale" ed il nick, se il canale <nome> non puo' essere
trovato.
Se il parametro "o" viene trasmesso, solo gli operatori, in funzione dello schema
di nome-utente fornito, verranno listati.
Risposte Numeriche:
ERR_NOSUCHSERVER (errore_server inesistente)
RPL_WHOREPLY (risposta_risposta al messaggio "WHO": )
RPL_ENDOFWHO (risposta_fine della risposta al messaggio "WHO": )
Esempi:
WHO *.fi ; lista tutti gli utenti coerenti con "*.fi".
WHO jto* o ; lista tutti gli utenti coerenti con "jto*" se sono
operatori.
4.5.2 Richiesta Whois
Comando: WHOIS
Parametri: [<server>] <schema-nick>[,<schema-nick>[,...]]
Questo messaggio e' usato per chiedere
informazioni su un particolare utente. Il server rispondera' a questo messaggio con diverse
risposte numeriche indicando i differenti status tra gli utenti coerenti con lo schema-nick,
di tutti quelli visibili al richiedente. Se non ci sono caratteri-jolly nel parametro
<schema-nick>, ogni informazione su quel nick che il richiedente sia autorizzato a
vedere, viene mostrata. Pu essere fornita una lista di schemi-nick separati da una virgola
(',').
La versione piu' recente invia la richiesta ad uno specifico server. Questo perche' l'
attuale periodo di inattivita' di un utente e' conosciuto solo al server al quale l'utente
e' direttamente connesso, mentre tutte le altre informazioni sono note universalmente. (13)
Risposte Numeriche:
ERR_NOSUCHSERVER (errore_server inesistente)
ERR_NONICKNAMEGIVEN (errore_non e' stato fornito alcun nick)
ERR_NOSUCHNICK (errore_nick inesistente)
RPL_WHOISUSER (risposta_WHOIS: utente)
RPL_WHOISCHANNELS (risposta_WHOIS: canali)
RPL_WHOISSERVER (risposta_WHOIS: server)
RPL_WHOISOPERATOR (risposta_WHOIS: operatore)
RPL_WHOISIDLE (risposta_WHOIS: periodo di inattivita')
RPL_AWAY (risposta_utente "fuori stanza")
RPL_ENDOFWHOIS (risposta_fine del WHOIS)
Esempi:
WHOIS wiz ; ritorna le informazioni disponibili
dell'utente con nick WiZ
WHOIS eff.org trillian ; chiede al server eff.org informazioni sull'
user trillian
4.5.3 Domanda Whowas
Comando: WHOWAS
Parametri: <nick> [<conto> [<server>]]
Whowas chiede informazioni su un nick che non
esiste piu' a causa di un cambio di nick oppure a causa dell' uscita da IRC dell'utente. In
risposta a questa richiesta, il server ricerca nel suo archivio storico dei nick, cercando i
nick che sono lessicalmente uguali (non si usano caratteri-jolly in questo caso). L'
archivio storico e' controllato a ritroso e fornisce per prima la ricorrenza piu' recente
per il nick. Se viene trovata piu' di una presenza, vengono fornite piu' risposte, fino a un
numero <conto> di casi (oppure la casistica completa, se non viene precisato il
parametro <conto>). Se il parametro <conto> contiene un numero non positivo,
allora viene effettuata una ricerca completa.
Risposte Numeriche:
ERR_NONICKNAMEGIVEN (errore_non e' stato fornito alcun nick)
ERR_WASNOSUCHNICK (errore_nick inesistente)
RPL_WHOWASUSER (risposta_WHOWAS: utente)
RPL_WHOWASERVER (risposta_WHOWAS: server)
RPL_ENDOFWHOWAS (risposta_fine del WHOWAS)
Esempi:
WHOWAS Wiz ; ritorna tutte le informazioni storiche sul nick
"WiZ";
WHOWAS Mermaid 9 ; ritorna informazioni su un numero massimo di 9
ricorrenze piu' recenti per il nick Mermaid
nell' archivio storico per i nicks.
WHOWAS Trillian 1 *.edu ; ritorna l' informazione storica piu' recente per
"Trillian" dal primo server coerente con lo
schema: "*.edu".
4.6 Altri Messaggi
I messaggi di questa categoria non rientrano in nessuna di quelle sopraelencate,
ma sono parte integrante del protocollo.
4.6.1 Messaggio Kill
Comando: KILL
Parametri: <nick> <commento>
Il messaggio KILL viene usato per far chiudere,
al server locale che la supporta materialmente, una connessione client-server. KILL viene
usato dai servers quando incontrano una presenza duplice nella lista di nicks validi, per
rimuovere ambedue gli utenti. Questo comando e' disponibile anche agli operatori.
I clients che possiedono algoritmi per la riconnessione automatica rendono di fatto questo
comando poco utile, dal momento che la sconnessione risulta breve. Comunque esso interrompe
il flusso dei dati e puo' essere impiegato per fermare un uso scorretto di grandi quantita'
di informazioni. Ogni utente puo' scegliere di ricevere i messaggi KILL generati da altri
per tenere d'occhio i potenziali aree problematiche.
In una arena dove e' necessario che i nicks siano in ogni momento tassativamente unici,
messaggi KILL vengono generati ogniqualvolta vengono scoperti dei "duplicati"
(tentativo di registrare due utenti con lo stesso nick) nella speranza che ambedue
spariscano e ne riappaia solo uno.
Il <commento> fornito deve riflettere la ragione effettiva del KILL. Per i KILLs
generati da server ,commento> e' generalmente costruito con i dettagli relativi all'
origine dei nicks in conflitto. Per quelli generati dagli utenti e' lasciato ad essi l'onere
di fornire una ragione adeguata che soddisfi chi vede il comando. Per prevenire/scoraggiare
la creazione di KILLs truccati, per nascondere l' identita' del KILLer (generatore del
comando), il <commento> mostra anche un 'kill-path' (traccia del KILL) che viene
aggiornato da ogni server che esso attraversa. L'aggiornamento consiste nell'aggiunta, da
parte di ogni server, del proprio nome alla traccia.
Risposte Numeriche:
ERR_NOPRIVILEGES (errore_non hai i privilegi dell'operatore)
ERR_NEEDMOREPARAMS (errore_necessitano piu' parametri)
ERR_NOSUCHNICK (errore_nick inesistente)
ERR_CANTKILLSERVER (errore_non puo' "uccidere" un server)
Esempio:
KILL David (csd.bu.edu <- tolsun.oulu.fi) ; collisione di nickname
tra csd.bu.edu e tolson.oulu.fi
NOTA:
E' chiaramente auspicabile che solo gli operatori siano abilitati a chiudere una connessione
di altri utenti con il messaggio KILL. In un mondo ideale nemmeno gli operatori avrebbero
bisogno di farlo, lasciando che fossero i servers ad occuparsi del problema.
4.6.2 Messaggio Ping
Comando: PING
Parametri: <server1> [<server2>]
Il messaggio PING e' usato per controllare la
presenza di un utente attivo all'altro capo della connessione. Un messaggio PING viene
mandato ad intervalli regolari, se non viene rilevata nessuna attivita' proveniente da una
connessione. Se una connessione non risponde ad un comando PING, entro un certo periodo di
tempo, quella connessione viene chiusa.
Qualsiasi client riceva un messaggio PING deve rispondere al <server1> (server che ha
inviato il messaggio PING) il piu' in fretta possibile con un appropriato messaggio PONG,
per indicare che esso e' presente e vivo. I servers non dovrebbero rispondere ai comandi
PING ma contare sui PING dall'altro capo della connessione per indicare che la connessione
e' attiva. Se viene specificato il parametro <server2>, il messaggio PING viene
inoltrato anche a quel server.
Risposte Numeriche:
ERR_NOORIGIN (errore_nessuna origine)
ERR_NOSUCHSERVER (errore_server inesistente)
Esempi:
PING tolsun.oulu.fi ; il server che invia un messaggio PING ad un
altro server per indicare che e' ancora attivo.
PING WiZ ; messaggio PING inviato al nick WiZ
4.6.3 Messaggio Pong
Comando: PONG
Parametri: <demone> [<demone2>]
Il messaggio PONG e' una risposte al messaggio
ping. Se viene fornito il parametro <demone2> questo messaggio deve essere inoltrato
anche a quel demone. Il parametro <demone> e' il nome del demone che ha risposto al
messaggio PING e ha generato questo messaggio.
Risposte Numeriche:
ERR_NOORIGIN (errore_nessuna origine)
ERR_NOSUCHSERVER (errore_server inesistente)
Esempi:
PONG csd.bu.edu tolsun.oulu.fi ; messaggio PONG da csd.bu.edu a
tolsun.oulu.fi
4.6.4 Messaggio Error
Comando: ERROR
Parametri: <messaggio d' errore>
L' uso del comando ERROR e' riservato ai server
per riportare ai propri operatori un errore grave oppure fatale. Esso puo' anche essere
inviato da un server all'altro ma non deve essere accettato se proveniente da un qualsiasi
normale client non meglio conosciuto.
Il messaggio ERROR e' usato solamente per rendere noti gli errori che si manifestano in un
link server-a-server. Un messaggio ERROR viene mandato al server che si trova all'altro capo
della connessione (il quale lo invia a tutti i suoi operatori connessi) come a tutti gli
operatori attualmente connessi. Il messaggio non deve essere passato ad altri servers da un
server che lo abbia ricevuto da un server.
Quando un server invia un messaggio ERROR ricevuto ai suoi operatori, il messaggio dovrebbe
essere contenuto in un messaggio NOTICE, indicando che il client non e' responsabile per
quell'errore.
Risposte Numeriche:
Nessuna.
Esempi:
ERROR :Server *.fi already exists;
messaggio ERROR all'altro server che ha causato
questo errore.
NOTICE WiZ :ERROR from csd.bu.edu -- Server *.fi already exists ;
stesso messaggio ERROR come sopra, ma mandato
all'utente WiZ sull'altro server.
5. MESSAGGI FACOLTATIVI
Questa sezione descrive i messaggi FACOLTATIVI. Essi non sono richiesti in una
implementazione server attiva del protocollo descritto in questo documento. Se il
trattamento di un messaggio opzionale non e' implementato, deve essere generato un apposito
messaggio di errore oppure un errore generico di comando sconosciuto. Se il messaggio e'
destinato ad un altro server deve essere passato oltre (e' richiesta una analisi
elementare). Le risposte numeriche adatte allo scopo sono elencate con i messaggi descritti
qui di seguito.
5.1 Messaggio Away
Comando: AWAY
Parametri: [messaggio]
Con il messaggio AWAY i clients possono
predisporre una riga di risposta automatica per ogni comando PRIVMSG loro indirizzato (non
ad un canale sul quale essi si trovano).
La risposta automatica viene inviata dal server al client mittente del comando PRIVMSG.
L'unico server a rispondere e' quello sul quale il client e' localmente connesso.
Il messaggio AWAY usato sia con un parametro (per predisporre un messaggio AWAY) che senza
parametri (per annullare il messaggio AWAY).
Risposte Numeriche:
RPL_UNAWAY (risposta_utente non in AWAY)
RPL_NOWAWAY (risposta_utente in AWAY)
Esempi:
AWAY :Gone to lunch. Back in 5 ;
predispone il messaggio away in "Gone to lunch. Back in
5" (Andato a pranzo, Di ritorno in 5 minuti).
:WiZ AWAY ;
disattiva il messaggio away di WiZ.
5.2 Messaggio Rehash
Comando: REHASH
Parametri: Nessuno
Il messaggio REHASH puo' essere usato dall'operatore per forzare il server a rileggere e
riprocessare il suo file di configurazione.
Risposte Numeriche:
RPL_REHASHING (risposta_rehashing in corso)
ERR_NOPRIVILEGES (errore_non hai i privilegi dell'operatore)
Esempi:
REHASH ; messaggio da un client, con status operatore, ad un server per
chiedergli di rileggere il suo file di configurazione.
5.3 Messaggio Restart
Comando: RESTART
Parametri: Nessuno
Il comando RESTART puo' essere usato
esclusivamente da un operatore per forzare un server ad attivare la procedura di riavvio.
Questo messaggio e' facoltativo in quanto potrebbe essere visto come un rischio permettere a
persone non meglio qualificate di connettersi al server come operatori ed eseguire questo
comando, causando (come minimo) un; interruzione del servizio. Il comando RESTART deve
sempre essere processato completamente dal server al quale il client mittente e' connesso, e
non deve essere inoltrato ad altri server.
Risposte Numeriche:
ERR_NOPRIVILEGES (errore_non hai i privilegi dell'operatore)
Esempi:
RESTART ; non sono richiesti parametri.
5.4 Messaggio Summon
Comando: SUMMON
Parametri: <utente> [<server>]
Il comando SUMMON puo' essere usato per
inviare, ad utenti che si trovano su una macchina su cui e' attivo un server IRC, un
messaggio per chiedere loro di unirsi a IRC. Questo messaggio mandato solamente se il server
destinazione del messaggio: a) ha il comando SUMMON abilitato; b) l'utente e' in linea; c)
il server che processa il comando puo' inviare dell' output all'utente.
Se non viene dato alcun parametro <server>, il server cerca di SUMMON (convocare) l'
<utente> sul server sul quale il client e' connesso che viene considerato come server
destinazione.
Se SUMMON non e' attivo su un server, esso deve mandare la risposta numerica
ERR_SUMMONDISABLED e passare oltre il messaggio. (14)
Risposte Numeriche:
ERR_NORECIPIENT (errore_nessun destinatario)
ERR_FILEERROR (errore_errore sul file)
ERR_NOLOGIN (errore_non in linea)
ERR_NOSUCHSERVER (errore-server inesistente)
RPL_SUMMONING (risposta_convocazione in corso)
Esempi:
SUMMON jto ; convoca l'utente jto sulla macchina
del server
SUMMON jto tolsun.oulu.fi ; convoca l'utente jto sulla macchina
sulla quale e' attivo il server
"tolsun.oulu.fi".
5.5 Comando Users, Utenti
Comando: USERS
Parametri: [<server>]
Il comando USERS invia in risposta una lista di
utenti collegati ad un server in un formato simile a quello di who(1), rusers(1) e
finger(1). Alcuni disabilitano questo comando dal loro server per ragioni di sicurezza. Se
disabilitato, la relativa risposta numerica, indicante la disabilitazione, deve essere
fornita.
Risposte Numeriche:
ERR_NOSUCHSERVER (errore_server inesistente)
ERR_FILEERROR (errore_errore sul file)
ERR_USERSDISABLED (errore_comando USERS disabilitato)
RPL_USERSSTART (risposta_USERS: inizio)
RPL_USERS (risposta_USERS)
RPL_NOUSERS (risposta_nessun utente)
RPL_ENDOFUSERS (risposta_fine degli utenti)
Risposta se disabilitato:
ERR_USERSDISABLED (errore_comando USERS disabilitato)
Esempi:
USERS eff.org ; richiede una lista di utenti connessi
su eff.org
:John UTENTI tolsun.oulu.fi ; richiesta di John per una lista di
utenti connessi sul server
tolsun.oulu.fi
5.6 Comando Operwall
Comando: WALLOPS
Parametri: Testo da mandare a tutti gli operatori in linea
Manda un messaggio a tutti gli operatori in linea. Dopo aver implementato il WALLOPS come un
comando a disposizione del generico utente, ci si e' accorti che di esso veniva spesso e
volentieri fatto un uso improprio per mandare messaggi ad un sacco di gente (in maniera
molto simile al WALL). Per questo motivo sarebbe bene che la corrente implementazione del
comando WALLOPS sia considerata come un esempio e che siano in futuro riconosciuti solo i
servers come mittenti dei WALLOPS.
Risposte Numeriche:
ERR_NEEDMOREPARAMS (Errore_necessitano piu' parametri)
Esempi:
:csd.bu.edu WALLOPS :Connect '*.uiuc.edu 6667' from Joshua;
messaggio WALLOPS da csd.bu.edu che annuncia un messaggio CONNECT
ricevuto da Joshua e messo in atto.
5.7 Messaggio Userhost
Comando: USERHOST
Parametri: <nick>{<carattere-spazio><nickname>}
Il comando USERHOST prende una lista contenente
fino a 5 nicks separati da un carattere spazio, e invia una lista di informazioni su ogni
nick che ha trovato. La lista ha le risposte separate da uno spazio.
Risposte Numeriche:
ERR_NEEDMOREPARAMS (Errore_necessitano piu' parametri)
RPL_USERHOST (risposta_USERHOST)
Esempi:
USERHOST Wiz Michael Marty p ; Richiesta di informazioni USERHOST sui
nick "Wiz", "Michael", "Marty" e "p"
5.8 Messaggio ISON
Comando: ISON
Parametri: <nick>{<carattere-spazio><nick>}
Il comando ISON e' stato implementato per
fornire un mezzo veloce ed efficiente per sapere se un dato nick e' correntemente presente
su IRC. ISON prevede solo un (1) parametro: una lista di nicks separati da spazi. Ogni nick
della lista che sia attualmente presente, viene aggiunto dal server alla stringa contenente
le risposte. Cosi' la stringa di risposta puo' essere vuota (nessuno dei nick presente),
oppure viene inviata una copia esatta della stringa dei parametro (tutti i nick presenti) o
qualsiasi altra sottoinsieme dei nicks dati nel parametro. L'unico limite sul numero di
nicks che puo' essere controllato, e' dato dalla lunghezza della riga che non deve eccedere
i 512 caratteri, altrimenti verra' troncata dal server.
ISON e' processato solamente dal server locale del client che manda il comando e non viene
passato ad altri servers.
Risposte Numeriche:
ERR_NEEDMOREPARAMS (Errore_necessitano piu' parametri)
RPL_ISON (risposta_utente in linea)
Esempi:
ISON phone trillian WiZ jarlek Avalon Angel Monstah ;
esempio di richiesta ISON per 7 nicks.
6. RISPOSTE
Quella che segue e' una lista di risposte numeriche che sono generate in risposta ai comandi
descritti sopra. Ogni risposta numerica e' data con il suo numero, il nome e la relativa
stringa esplicativa.
6.1 Risposte d' Errore
401 ERR_NOSUCHNICK "<nickname> :No such nick/channel"
- Risposta inviata per indicare che il parametro nickname dato ad un
comando e' attualmente non in uso.
402 ERR_NOSUCHSERVER "<server name> :No such server"
- Risposta inviata per indicare che il nome del server dato attualmente
non esiste.
403 ERR_NOSUCHCHANNEL "<channel name> :No such channel"
- Risposta inviata per indicare che il nome del canale fornito non
e' valido.
404 ERR_CANNOTSENDTOCHAN "<channel name> :Cannot send to channel"
- Risposta inviata ad un utente il quale: a) non si trova su un canale
con mode +n, oppure b) non e' un operatore di canale (o non e' in mode
utente +v) su un canale in mode +m e sta cercando di inviare un PRIVMSG
a quel canale.
405 ERR_TOOMANYCHANNELS "<channel name> :You have joined too
many channels"
- Risposta inviata agli utenti quando si sono aggregati al numero massimo
permesso di canali, e stanno cercando di aggregarsi ad un altro canale.
406 ERR_WASNOSUCHNICK "<nickname> :There was no such nickname"
- Mandata in risposta ad un WHOWAS per indicare che non ci sono
informazioni nell' archivio storico per quel nick.
407 ERR_TOOMANYTARGETS "<target> :Duplicate recipients.
No message \ delivered"
- Replica inviata in risposta ad un client che sta cercando di mandare
un PRIVMSG/NOTICE usando il formato di destinazione user@host e per un
user@host che ha diverse presenze al momento attuale.
409 ERR_NOORIGIN ":No origin specified"
- Messaggio PING o PONG al quale manca il parametro che indica il
mittente, necessario dal momento che questi comandi devono funzionare
senza prefissi validi.
411 ERR_NORECIPIENT ":No recipient given (<Command>)"
412 ERR_NOTEXTTOSEND ":No text to send"
413 ERR_NOTOPLEVEL "<mask> :No toplevel domain specified"
414 ERR_WILDTOPLEVEL "<mask> :Wildcard in toplevel domain"
- 412 / 414 sono date da PRIVMSG per indicare che il messaggio non e'
stato inoltrato per qualche ragione. ERR_NOTOPLEVEL e ERR_WILDTOPLEVEL
sono errori che vengono inviati come risposta quando si tenta un uso
non valido di "PRIVMSG $<server>" o "PRIVMSG #<host>".
421 ERR_UNKNOWNCOMMAND "<Command> :Unknown Command"
- Risposta inviata ad un client registrato per indicare che il comando
proposto e' sconosciuto al server.
422 ERR_NOMOTD ":MOTD File is missing"
- Il server non ha potuto aprire il proprio file MOTD. [MOTD = Message
Of The Day (messaggio del giorno) - Nota del revisore]
423 ERR_NOADMININFO "<server> :No administrative info
available"
- Risposta inviata da un server in risposta ad un messaggio ADMIN quando
c'e' un errore nel reperimento delle informazioni.
424 ERR_FILEERROR ":File error doing <file op> on
<file>"
- Messaggio di errore generico, usato per informare il fallimento di un
operazione di trattamento di file(s) durante il trattamento del
messaggio.
431 ERR_NONICKNAMEGIVEN ":No nickname given"
- Risposta inviata quando un parametro nickname richiesto per l'
esecuzione di un comando non viene trovato
432 ERR_ERRONEUSNICKNAME "<nick> :Erroneus nickname"
- Risposta inviata dopo aver ricevuto un messaggio NICK il quale contiene
caratteri non compresi nel set definito per i nicks. Si veda la sezione
4.1.2 per dettagli sui nickname validi.
433 ERR_NICKNAMEINUSE "<nick> :Nickname is already
in use"
- Risposta inviata quando un messaggio NICK ha come risultato un
tentativo di cambiare il nickname con un nickname gia' correntemente
in uso.
436 ERR_NICKCOLLISION "<nick> :Nickname collision KILL"
- Risposta inviata da un server ad un client quando scopre una collisione
di nicknames (registrazione di un nick che gia' esiste da parte di un
altro server).
441 ERR_USERNOTINCHANNEL "<nick> <channel> :They aren't on that
channel"
- Risposta inviata dal server per indicare che l'utente destinatario del
comando non e' sul canale dato.
442 ERR_NOTONCHANNEL "<channel> :You're not on that
channel"
- Risposta inviata dal server ogni volta che un client tenta un comando
riferito ad un canale del quale non e' membro.
443 ERR_USERONCHANNEL "<user> <channel> :is already on channel"
- Risposta inviata quando un client cerca di invitare un utente nel
canale nel quale gia' si trovano ambedue.
444 ERR_NOLOGIN "<user> :User not logged in"
- Risposta inviata dopo che il comando SUMMON per un utente non stato
portato a termine in quanto l'utente non era in linea.
445 ERR_SUMMONDISABLED ":SUMMON has been disabled"
- Risposta inviata come risposta al comando SUMMON. Deve essere inviata
da ogni server sul quale questo comando non e' implementato..
446 ERR_USERSDISABLED ":USERS has been disabled"
- Risposta inviata in risposta al comando USERS. Deve essere inviata da
ogni server sul quale questo comando non e' implementato.
451 ERR_NOTREGISTERED ":You have not registered"
- Risposta inviata dal server per indicare che il client deve essere
registrato prima che il server permetta ad esso di essere analizzato
nei dettagli.
461 ERR_NEEDMOREPARAMS "<Command> :Not enough parameters"
- Risposta inviata dal server in risposta a numerosi comandi per indicare
che il client non ha fornito un numero di parametri sufficiente.
462 ERR_ALREADYREGISTRED ":You may not reregister"
- Risposta inviata dal server per ogni connessione che cerchi di cambiare
parte delle notizie registrate (quali password o informazioni
concernenti l' utente) mediante un secondo comando USER.
463 ERR_NOPERMFORHOST ":Your host isn't among the privileged"
- Risposta inviata ad un client che cerca di registrarsi su un server che
non permette connessioni dalla macchina che tenta la connessione.
464 ERR_PASSWDMISMATCH ":Password incorrect"
- Risposta inviata per indicare il fallimento di un tentativo di
registrare una connessione per la quale e' richiesta una parola
d'ordine e quest' ultima non e' stata fornita oppure e' stata indicata
in forma non corretta.
465 ERR_YOUREBANNEDCREEP ":You are banned from this server"
- Risposta inviata dopo un tentativo di connessione e registrazione su un
server predisposto per negarci esplicitamente la connessione.
467 ERR_KEYSET "<channel> :Channel key already set"
471 ERR_CHANNELISFULL "<channel> :Cannot join channel(+l)"
472 ERR_UNKNOWNMODE "<char> :is unknown mode char to me"
473 ERR_INVITEONLYCHAN "<channel> :Cannot join channel (+i)"
474 ERR_BANNEDFROMCHAN "<channel> :Cannot join channel (+b)"
475 ERR_BADCHANNELKEY "<channel> :Cannot join channel (+k)"
481 ERR_NOPRIVILEGES ":Permission Denied- You're not an IRC
operator"
- Ogni comando che richiede i privilegi di operatore per essere eseguito,
deve inviare questa risposta d' errore per indicare che il tentativo di
eseguire il comando non ha avuto successo.
482 ERR_CHANOPRIVSNEEDED "<channel> :You're not channel operator"
- Ogni comando che richiede i privilegi di operatore di canale per
essere eseguito (quale, ad esempio, il messaggio MODE) deve mandare
questo errore se il client sta facendo un tentativo di eseguire il
comando e non e' un operatore sul canale specificato.
483 ERR_CANTKILLSERVER ":You cant kill a server!"
- Ogni tentativo di usare il comando KILL su un server deve essere
rifiutato e questo messaggio d' errore deve essere inviato direttamente
al client.
491 ERR_NOOPERHOST ":No O-lines for your host"
- Se un client invia un messaggio OPER ed il server non e' stato
configurato per permettere connessioni dalla macchina del client come
operatore, deve essere inviata questa risposta d' errore.
501 ERR_UMODEUNKNOWNFLAG ":Unknown MODE flag"
- Risposta inviata dal server per indicare che un messaggio MODE e' stato
inviato con un parametro nickname e che la modalita' mode inviata non e'
stata riconosciuta.
502 ERR_USERSDONTMATCH ":Can't change mode for other users"
- Errore Inviato a qualsiasi utente che cerchi di prender visione o
cambiare gli user mode per un utente che non sia se stesso.
6.2 Risposte ai comandi.
302 RPL_USERHOST ":[<reply>{<space><reply>}]"
- Formato di replica usato da USERHOST per elencare risposte alla lista
che compare nella richiesta. La stringa di replica e' composta come
segue:
<reply> ::= <nick>['*'] '=' <'+'|'-'><hostname>
L'asterisco '*' indica se un client e' registrato come operatore. I
caratteri '-' o '+' indicano rispettivamente se il client ha predisposto
oppure no un messaggio di AWAY.
303 RPL_ISON ":[<nick> {<space><nick>}]"
- Formato di replica usato da ISON per elencare risposte alla lista che
compare nella richiesta.
301 RPL_AWAY "<nick> :<away message>"
305 RPL_UNAWAY ":You are no longer marked as being
away"
306 RPL_NOWAWAY ":You have been marked as being away"
- Queste repliche sono usate con il comando AWAY (se permesso). RPL_AWAY
e' inviata ad ogni client che invii un messaggio ad un client che abbia
settato il comando AWAY. RPL_AWAY e' inviata solo dal server al quale
il client e' connesso. Le repliche RPL_UNAWAY e RPL_NOWAWAY sono
inviate quando il client annulla o predispone il messaggio AWAY.
311 RPL_WHOISUSER "<nick> <user> <host> * :<real name>"
312 RPL_WHOISSERVER "<nick> <server> :<server info>"
313 RPL_WHOISOPERATOR "<nick> :is an IRC operator"
317 RPL_WHOISIDLE "<nick> <integer> :seconds idle"
318 RPL_ENDOFWHOIS "<nick> :End of /WHOIS list"
319 RPL_WHOISCHANNELS "<nick> :{[@|+]<channel><space>}"
- Le repliche dalla 311 alla 313 e dalla 317 alla 319 sono tutte generate
in risposta ad un messaggio WHOIS. Ammesso che sia presente un numero
di parametri sufficiente, il server che risponde deve formulare o una
risposta numerica tra quelle sopra elencate (nel caso che il nick
richiesto venga trovato), oppure deve inviare una risposta di errore.
L'asterisco '*' in RPL_WHOISUSER e' in questo caso inserito come
carattere e non come wild card. Per ogni insieme di risposte, solamente
RPL_WHOISCHANNELS puo' apparire piu' di una volta (per liste lunghe di
nomi di canali). Il caratteri '@' e '+' affiancati al nome del canale
indicano se un client e' operatore di quel canale o se gli e' stato
accordato il permesso di parlare su un canale moderato. La replica
RPL_ENDOFWHOIS e' usata per segnalare la fine del trattamento del
messaggio WHOIS.
314 RPL_WHOWASUSER "<nick> <user> <host> * :<real name>"
369 RPL_ENDOFWHOWAS "<nick> :End of WHOWAS"
- Quando risponde ad un messaggio WHOWAS, il server deve usare le
repliche RPL_WHOWASUSER, RPL_WHOISSERVER o ERR_WASNOSUCHNICK per ogni
nickname della lista presentata. Alla fine di ogni gruppo di risposte,
deve comparire un RPL_ENDOFWHOWAS (anche se c' e' stata una sola
risposta e questa era un errore).
321 RPL_LISTSTART "Channel :Users Name"
322 RPL_LIST "<channel> <# visible> :<topic>"
323 RPL_LISTEND ":End of /LIST"
- Le repliche RPL_LISTSTART, RPL_LIST, RPL_LISTEND segnano
rispettivamente l'inizio, le vere e proprie risposte con dati, e la
fine delle repliche del server al comando LIST. Se non ci sono canali
disponibili sui quali ritornare notizie, devono essere inviate solo le
repliche di inizio e fine.
324 RPL_CHANNELMODEIS "<channel> <mode> <mode params>"
331 RPL_NOTOPIC "<channel> :No topic is set"
332 RPL_TOPIC "<channel> :<topic>"
- Quando si manda un messaggio TOPIC per definire il topic del canale,
viene inviata una delle due repliche. SE il topic e' definito viene
Inviata la replica RPL_TOPIC, diversamente viene Inviata la replica
RPL_NOTOPIC.
341 RPL_INVITING "<channel> <nick>"
- Risposta inviata dal server per indicare che il tentativo INVITE e'
stato accettato e quindi e' stato segnalato al client.
342 RPL_SUMMONING "<user> :Summoning user to IRC"
- Risposta inviata da un server in risposta ad un messaggio SUMMON per
indicare che sta convocando quell'utente.
351 RPL_VERSION "<version>.<debuglevel> <server>
:<comments>"
- Risposta inviata dal server per fornire informazioni di tipo VERSION.
Il parametro <version> e' la versione del software in uso (incluse
tutte le revisioni ed i livelli di aggiornamento) e il parametro
<debuglevel> e' usato per indicare se il server lavora in "debug mode"
[Modo diagnostico - Nota del revisore]. Il campo "comments" puo'
contenere commenti sulla versione oppure ulteriori notizie sulla
versione.
352 RPL_WHOREPLY "<channel> <user> <host> <server>
<nick>\<H|G>[*][@|+] :<hopcount> <real name>"
315 RPL_ENDOFWHO "<name> :End of /WHO list"
- La coppia di repliche RPL_WHOREPLY e RPL_ENDOFWHO sono usate per
rispondere ad un messaggio WHO. La replica RPL_WHOREPLY e' inviata
solamente se e' stato rintracciato un riscontro appropriato alla
domanda WHO. Se viene data una lista di parametri a supporto del
messaggio WHO message, deve essere inviata una replica RPL_ENDOFWHO
dopo aver processato ogni voce della lista, intendendo per voce il
parametro <name>.
353 RPL_NAMREPL "<channel> :[[@|+]<nick>
[[@|+]<nick>[...]]]"
366 RPL_ENDOFNAMES "<channel> :End of /NAMES list"
- Per rispondere ad un messaggio NAMES, viene inviata una coppia di
repliche composta da RPL_NAMREPLY e RPL_ENDOFNAMES dal server al
client. Se non viene trovato alcun canale, tra quelli dati con la
domanda, allora viene inviata solamente la replica RPL_ENDOFNAMES. L'
eccezione si da' quando il messaggio NAMES viene inviato senza parametri
e tutti i canali visibile ed i loro contenuti, sono inviati in una serie
di repliche RPL_NAMEREPLY con RPL_ENDOFNAMES a segnarne la fine.
364 RPL_LINKS "<mask> <server> :<hopcount> <serverinfo>"
365 RPL_ENDOFLINKS "<mask> :End of /LINKS list"
- In risposta al messaggio LINKS, un server deve inviare delle repliche
usando la risposta numerica RPL_LINKS, segnando la fine della lista
usando la replica RPL_ENDOFLINKS.
367 RPL_BANLIST "<channel> <banid>"
368 RPL_ENDOFBANLIST "<channel> :End of channel ban list"
- Quando elenca i 'bans' attivi per un dato canale, al server si richiede
di inviare una lista usando le repliche RPL_BANLIST e RPL_ENDOFBANLIST.
Un messaggio separato RPL_BANLIST e' inviato per ogni ban attivo. Dopo
che i ban sono stati elencati (oppure se non ne era prendente nessuno)
deve essere inviata la replica RPL_ENDOFBANLIST.
371 RPL_INFO ":<string>"
374 RPL_ENDOFINFO ":End of /INFO list"
- Un server che risponde ad un messaggio INFO deve essere in grado di
mandare tutte le sue 'informazioni' in una serie di repliche RPL_INFO
con la replica RPL_ENDOFINFO ad indicare la fine della serie
di risposte.
375 RPL_MOTDSTART ":- <server> Message of the day - "
372 RPL_MOTD ":- <text>"
376 RPL_ENDOFMOTD ":End of /MOTD Comando"
- Quando viene trovato il file MOTD in risposta al messaggio MOTD, il
file viene mostrato riga per riga, ognuna delle quali non e' piu' lunga
di 80 caratteri, usando il formato di replica RPL_MOTD. Questa replica
(RPL_MOTD) dovrebbe essere preceduta da RPL_MOTDSTART e seguita da
RPL_ENDOFMOTD.
381 RPL_YOUREOPER ":You are now an IRC operator"
- La replica RPL_YOUREOFOR e' inviata ad un client che ha espletato con
successo un messaggio OPER e guadagnato lo status operatore.
382 RPL_REHASHING "<config file> :Rehashing"
- Se viene usata l'opzione REHASH ed un operatore invia un messaggio
REHASH, a quell'operatore viene inviata la replica RPL_REHASHING.
391 RPL_TIME "<server> :<string showing server's
local time>"
- Quando un server risponde ad un messaggio TIME, deve inviare la
risposta usando il format RPL_TIME descritto sopra. La stringa che
mostra l'orario deve contenere solamente il giorno e l'orario corretti.
Non sono necessari altri requisiti.
392 RPL_USERSSTART ":UserID Terminal Host"
393 RPL_USERS ":%-8s %-9s %-8s"
394 RPL_ENDOFUSERS ":End of users"
395 RPL_NOUSERS ":Nobody logged in"
- Quando il messaggio USER e' trattato da un server, sono usate le
repliche RPL_USERSTART, RPL_USERS, RPL_ENDOFUSERS e RPL_NOUSERS.
La replica RPL_USERSSTART deve essere inviata per prima, seguita o da
una sequenza di RPL_USERS, oppure da una singola RPL_NOUSER. Per ultima
deve essere inviata una RPL_ENDOFUSERS.
200 RPL_TRACELINK "Link <version & debug level> <destination>
\ <next server>"
201 RPL_TRACECONNECTING "Try. <class> <server>"
202 RPL_TRACEHESHAKE "H.S. <class> <server>"
203 RPL_TRACEUNKNOWN "???? <class> [<client IP address in
dot form>]"
204 RPL_TRACEOPERATOR "Oper <class> <nick>"
205 RPL_TRACEUSER "User <class> <nick>"
206 RPL_TRACESERVER "Serv <class> <int>S<int>C <server> \
<nick!user|*!*>@<host|server>"
208 RPL_TRACENEWTYPE "<newtype> 0 <client name>"
261 RPL_TRACELOG "File <logfile> <debug level>"
- Le repliche RPL_TRACE* sono tutte inviate dal server in risposta ad un
messaggio TRACE. Quante ne vengano inviate dipende dal messaggio TRACE
e se questo sia stato inviato da un operatore oppure da un normale
utente. Non c' e' un ordine predefinito per quale replica debba essere
inviata per prima. Le repliche RPL_TRACEUNKNOWN, RPL_TRACECONNECTING e
RPL_TRACEHESHAKE sono tutte usate per connessioni che non sono state
stabilite in maniera completa e risultano sconosciute, oppure che sono
ancora in corso di connessione, oppure stanno completando il processo
di 'server handshake'. La replica RPL_TRACELINK e' inviata da qualsiasi
server che tratta un messaggio TRACE e deve passarlo ad un altro server.
La lista di RPL_TRACELINKs inviata in risposta ad un comando TRACE che
attraversa la rete IRC dovrebbe riflettere l' assetto effettivo delle
connessioni tra i servers lungo quel percorso. La replica
RPL_TRACENEWTYPE deve essere usata per ogni connessione che non rientra
nelle altre categorie ma viene comunque mostrata.
211 RPL_STATSLINKINFO "<linkname> <sendq> <sent messages> \ sent
bytes> <received messages> \ <received bytes>
<time open>"
212 RPL_STATSCOMMANDS "<Command> <count>"
213 RPL_STATSCLINE "C <host> * <name> <port> <class>"
214 RPL_STATSNLINE "N <host> * <name> <port> <class>"
215 RPL_STATSILINE "I <host> * <host> <port> <class>"
216 RPL_STATSKLINE "K <host> * <username> <port> <class>"
218 RPL_STATSYLINE "Y <class> <ping frequency> <connect \
frequency> <max sendq>"
219 RPL_ENDOFSTATS "<stats letter> :End of /STATS report"
241 RPL_STATSLLINE "L <hostmask> * <servername> <maxdepth>"
242 RPL_STATSUPTIME ":Server Up %d days %d:%02d:%02d"
243 RPL_STATSOLINE "O <hostmask> * <name>"
244 RPL_STATSHLINE "H <hostmask> * <servername>"
221 RPL_UMODEIS "<user mode string>"
- Per rispondere ad una domanda sul mode di un client viene inviata la
replica RPL_UMODEIS.
251 RPL_LUSERCLIENT ":There are <integer> user and <integer>
\invisible on <integer> servers"
252 RPL_LUSEROP "<integer> :operator(s) online"
253 RPL_LUSERUNKNOWN "<integer> :unknown connection(s)"
254 RPL_LUSERCHANNELS "<integer> :channels formed"
255 RPL_LUSERME ":I have <integer> clients e <integer>
\ servers"
- Mentre processa un messaggio LUSERS, il server invia degli insiemi di
risposte dalla 251 alla 255. Mentre risponde, il server deve inviare
RPL_LUSERCLIENT e RPL_LUSERME. Le altre risposte vengono inviate
solamente se viene trovato per loro un conteggio diverso da 0.
256 RPL_ADMINME "<server> :Administrative info"
257 RPL_ADMINLOC1 ":<admin info>"
258 RPL_ADMINLOC2 ":<admin info>"
259 RPL_ADMINEMAIL ":<admin info>"
- Quando risponde ad un messaggio ADMIN, il server e' tenuto ad usare le
repliche (dalla 256 alla 259) elencate qui sopra e fornire un messaggio
di testo per ogni replica. Per la replica RPL_ADMINLOC1 il server deve
dare una descrizione di: citta', stato e paese in cui esso si trova,
seguita da informazioni sull' universita' e il dipartimento
(RPL_ADMINLOC2) e, per ultimo, il contatto amministrativo per il server
(e' richiesto un indirizzo e-mail) nella risposta RPL_ADMINEMAIL. (15)
6.3 Risposte numeriche riservate.
Queste risposte numeriche non state descritte prima in quanto esse rientrano in una delle
seguenti categorie:
1. non piu' in uso
2. riservate per un prevedibile uso futuro
3. correntemente in uso ma parte di un assetto prestazionale non generale dell' attuale
server IRC.
209 RPL_TRACECLASS
217 RPL_STATSQLINE
231 RPL_SERVICEINFO
232 RPL_ENDOFSERVICES
233 RPL_SERVICE
234 RPL_SERVLIST
235 RPL_SERVLISTEND
316 RPL_WHOISCHANOP
361 RPL_KILLDONE
362 RPL_CLOSING
363 RPL_CLOSEEND
373 RPL_INFOSTART
384 RPL_MYPORTIS
466 ERR_YOUWILLBEBANNED
476 ERR_BADCHANMASK
492 ERR_NOSERVICEHOST
7. Autenticazione di
clients e servers
I clients e i servers sono soggetti allo stesso livello di autenticazione. Per entrambi, per
ogni connessione fatta al server, viene effettuato un passaggio dall' IP al nome della
macchina (ed un controllo all' inverso su questo). Entrambe le connessioni sono poi soggette
ad un controllo sulla parola d' ordine (se ne e' stata definita una per quella connessione).
Questi controlli sono possibili su tutte le connessioni sebbene il controllo sulla parola d'
ordine sia usato, in generale, solamente con i server.
Un controllo addizionale, che sta diventando sempre piu' usuale, e' il controllo sull'
username (nome dell' utente) responsabile della connessione. Trovare lo username dall'altra
parte connessa comporta la connessione ad un server di autenticazione quale IDENT, come
viene descritto nel documento RFC 1413.
Dato che senza parole d' ordine non e' cosa facile determinare con sicurezza chi si trovi
all'altro capo di una connessione, l'uso delle parole d' ordine e' fortemente consigliabile
nelle connessioni tra servers in aggiunta a misure di altra natura quale l'uso di un ident
server.
8. Implementazioni attuali
L'unica implementazione corrente di questo protocollo e' IRC server versione 2.8.
[Naturalmente questa affermazione era valida al momento della pubblicazione di questo
documento nel maggio 1993: gia' al momento di questa traduzione (giugno 1997) non lo e'
piu'. - Nota del revisore]. (16) Versioni precedenti potevano implementare in parte o tutti
i comandi descritti in questo documento, sostituendo molte delle risposte numeriche con
messaggi NOTICE. Purtroppo, per esigenze di compatibilita' verso versioni precedenti, l'
implementazione di alcune parti di questo documento non e' conforme al modo in cui era stata
progettata. Una differenza notevole:
* il riconoscimento che ogni LF o CR che si trovino in un qualunque punto di un messaggio
marchino la fine di quel messaggio (invece di richiedere il CR-LF)
Il resto di questa sezione tratta argomenti che hanno valore soprattutto per coloro i quali
desiderino implementare un server, ma alcune parti del protocollo trovano un' utile e
diretta applicazione anche ai clients.
8.1 Protocollo Network: TCP - perche' esso trova qui un applicazione ottimale.
L'IRC e' stato implementato sulla base del TCP, dal momento che il TCP fornisce un
protocollo di rete affidabile e che ben si adatta al tipo e dimensione del sistema di
scambio di messaggi cui IRC appartiene. L'uso di IP multidirezionale costituisce un
alternativa, ma non e' disponibile su vasta scala al momento.
8.1.1 Sostegno per Unix sockets
Dato che il campo d'azione degli Unix sockets permette operazioni ascolto/connessione,
l'implementazione corrente puo' essere configurata in modo che essa ascolti ed accetti le
connessioni sia da client che da server su un socket di dominio Unix. Queste connessioni
vengono riconosciute come socket quando il nome dell'host inizia con il carattere '/'.
Quando il server fornisce delle informazioni sulle connessioni socket di dominio Unix, esso
deve sostituire l'host name effettivo con il pathname, a meno che non sia richiesto proprio
il nome effettivo del socket.
8.2 Analisi dei comandi
Per fornire un valido I/O (Input/Output) 'non-buffered' in rete, sia per i clients che per i
servers, ad ogni connessione viene assegnato un 'input buffer', dedicato, nel quale sono
memorizzati i risultati delle operazioni di lettura e delle analisi di comandi piu' recenti.
E' stata stabilita per il buffer un ampiezza di 512 bytes in modo che possa contenere un
messaggio completo, anche se, normalmente, contiene piu' di un comando per volta. Il buffer
dedicato viene analizzato dopo ogni operazione di lettura per verificare la presenza di
comandi validi. Quando accade di dover trattare nel buffer messaggi multipli da un client,
bisogna usare attenzione qualora un messaggio causi la rimozione del client.
8.3 Invio del messaggio
E' cosa molto comune trovare link della rete saturi oppure macchine, alle quali si inviano
dati, incapaci di inviare dati. Sebbene Unix tratti questo problema con la finestra TCP e
buffers interni, il server ha spesso enormi quantita' di dati da inviare (specialmente
quando si forma un nuovo link server-server) ed i piccoli buffers forniti nel kernel del
sistema operativo, non sono sufficienti per la lunga coda di dati in uscita. Per alleviare
questo problema viene usato una "send queue" (sequenza di invio) con i dati
organizzati in una struttura FIFO. [Acronimo di First In, First Out, un modello di
organizzazione di dati. - Nota del revisore] Una tipica "send queue" puo' arrivare
fino a 200 Kbytes di ampiezza in una rete IRC di grandi dimensioni, con una connessione alla
rete lenta, quando un nuovo server si connette.
Nel raccogliere dati dalle sue connessioni, un server in primo luogo leggera ed analizzera'
tutte le informazioni in entrata, mettendo in coda ogni dato da inviare all' esterno. Quando
tutti i dati in input disponibili sono stati trattati, la sequenza di dati preparata viene
inviata. Questo riduce il numero delle chiamate di sistema al comando write() (scrittura) e
permette al TCP il trattamento di pacchetti piu' grandi.
8.4 Connessione 'Liveness'
Per controllare quando una connessione si sia persa oppure non risponda piu', il server deve
fare un ping per ognuna delle sue connessioni dalle quali non riceve risposte da un dato
lasso di tempo.
Se una connessione non risponde in tempo, verra' chiusa seguendo le procedure appropriate.
Una connessione viene fatta cadere anche nel caso in cui la sua send queue (coda di dati da
inviare) cresce al di la del massimo consentito, in quanto e' senz' altro meglio chiudere
una connessione lenta piuttosto che il server si blocchi.
8.5 Stabilire una connessione server-client
Quando un client si connette ad un server IRC, gli viene inviato il comando MOTD (se
presente) come del resto il numero di utenti e di servers attualmente connessi (come avviene
per il comando LUSER). Viene inoltre richiesto al server di fornire un messaggio non ambiguo
che notifichi al client il suo nome e versione ed ogni altra informazione che possa sembrare
appropriata.
Dopo aver espletato queste funzioni, il server deve inviare il nickname del nuovo utente e
tutte le altre informazioni fornibili da lui stesso (Comando USER), come del resto le
notizie reperibili in altra sede (dai servers con funzione di DNS/authentication). Il server
deve inviare queste informazioni con NICK seguito da USER.
8.6 Stabilire una connessione server-server
Il procedimento usato per stabilire una connessione server-server presenta aspetti
particolarmente rischiosi, in quanto ci sono innumerevoli circostanze nelle quali e' molto
facile che vengano commessi errori - il meno rilevante dei quali sono le cosiddette
"race conditions". [Condizioni per la corretta risoluzione delle quali la
variabile tempo e' di importanza essenziale. - Nota del Revisore]
Dopo che un server ha ricevuto una connessione seguita dalla coppia di comandi PASS/SERVER,
riconosciuta valida, il server dovrebbe rispondere con le sue informazioni PASS/SERVER per
quella connessione, e con tutte le altre informazioni di stato che conosce, come viene
descritto qui di seguito.
Quando il server che inizia la connessione riceve la coppia di comandi PASS/SERVER,
anch'esso controlla che il server che risponde sia autenticato in maniera appropriata, prima
di accettare la connessione con quel server.
8.6.1 Scambio di informazioni di stato fra servers al momento della connessione
L'ordine delle informazioni di stato che vengono scambiate tra servers e' essenziale.
L'ordine richiesto e' il seguente:
* tutti gli altri servers conosciuti;
* tutte le informazioni conosciute sugli utenti;
* tutti le informazioni conosciute sui canali.
Le informazioni riguardanti i servers vengono inviate mediante messaggi SERVER, le
informazioni concernenti gli utenti con messaggi NICK/UTENTE/MODE/JOIN e le informazioni sui
canali via messaggi MODE.
NOTA: i topics dei canali *NON* vengono scambiati in questa circostanza: il comando TOPIC
cancella ed aggiorna ogni informazione topic precedente, cosicche', nella migliore delle
ipotesi, i due versanti della connessione cambierebbero i topics.
Passando per prime le informazioni di stato dei servers, tutte le collisioni tra servers che
gia esistano hanno luogo prima che possano aver luogo le collisioni sui nicks dovute al
fatto che un secondo server introduce un nick che gia esista su un altro). Dal momento che
la rete IRC e' capace di esistere solo come un grafo aciclico, potrebbe essere possibile che
la rete si sia gia riconnesso in un altra locazione: il luogo dove avviene la collisione tra
servers indica allora il luogo dove la rete necessita di uno split.
8.7 Terminazione di connessioni server-client
Quando una connessione client chiude, viene generato un messaggio QUIT, ad interesse del
client, dal server al quale il client era connesso. Non e' necessario generare od usare
altri messaggi.
8.8 Terminazione di connessioni server-server
Se una connessione server-server viene chiusa, che sia per un messaggio remoto SQUIT sia per
cause 'naturali', il resto della rete IRC connessa deve essere informata della sconnessione
dal server che ha scoperto la chiusura che inviera' una lista di SQUIT (una per ogni server
che si trova oltre la sconnessione) ed una lista di QUIT (una per ogni client nella stessa
posizione).
8.9 Seguire la traccia dei cambi di nickname
Tutti i servers IRC devono tenere una traccia storica dei cambi recenti di nick. Questo e'
richiesto per permettere al server di avere una possibilita' di restare in contatto con la
situazione quando cambi di nick si succedano a gran velocita' (race conditions) insieme con
comandi che trattano i nicks stessi. I comandi che devono tener traccia dei cambi di nick
sono:
* KILL (il nickname ha subito un KILL)
* MODE (+/- o,v)
* KICK (il nickname subisce dei KICK)
Per nessun altro comando devono essere
controllati i cambi di nick.
Nei casi sopra descritti, al server e' richiesto innanzi tutto di controllare l'esistenza
del nick, e poi di controllarne la storia per vedere a chi appartiene al momento (sempre se
qualcuno stia usando quel nickname !). Questo riduce le possibilita' di trovarsi in
situazioni difficoltose a causa della velocita' con cui si succedono le operazioni (race
conditions), ma difficolta' possono comunque verificarsi qualora il server finisca per
eseguire il comando su un client sbagliato. Quando si attua il tracciamento per i cambi di
nickname, come descritto qui sopra, si raccomanda che venga concesso un intervallo di tempo
e che vengano ignorati casi troppo vecchi.
Per avere un archivio storico ragionevole, un server dovrebbe essere in grado di tenere i
nick precedenti di ogni client che conosce, qualora tutti decidessero di cambiare. L'
ampiezza dell' archivio storico e' comunque limitata da fattori diversi (per esempio dalla
disponibilita' di memoria, ecc.).
8.10 Controllo del flood dei clients
Con una grande rete IRC di servers interconnessi, e' molto facile per qualsiasi client
connesso alla rete, di produrre un flusso continuo di messaggi che finisce non solo per
floodare [flood vale allagamento, alluvione, inondazione. - Nota del revisore] la rete, ma
anche per degradare il livello delle prestazioni erogate verso gli altri clients. Piuttosto
che richiedere ad ogni possibile vittima di provvedere alla propria protezione, la
protezione flood e' stata scritta nel server ed applicata a tutti i clients tranne che ai
servizi. L'algoritmo adottato segue il seguente schema:
* controlla se il `message timer' segna un tempo precedente rispetto all'orario corrente
(aggiornarlo, se necessario, per renderlo uguale al tempo corrente);
* leggere ogni dato presente proveniente dal client;
* mentre il timer e' avanti di meno di dieci secondi dall'orario corrente, analizza ogni
messaggio presente, e penalizza il client di 2 secondi per ogni messaggio;
il che significa, di fatto, che il client puo' mandare 1 messaggio ogni 2 secondi senza
subire penalita'.
8.11 Letture veloci per evitare blocchi
In un ambiente real-time, e' essenziale che tutte le azioni dei servers attendano il minor
tempo possibile per essere espletate, cosicche' tutti i clients siano serviti in modo equo.
Ovviamente questo richiede un non-blocking I/O su tutte le operazioni read/write del
network. Per le connessioni server normali, questo non sarebbe difficile, ma ci sono altre
operazioni di supporto che possono causare il blocco temporaneo del server (quali la lettura
dei dischi). Dove possibile, una tale attivita' dovrebbe essere espletata con pause di
funzionamento brevi.
8.11.1 Lettura veloce dell' Hostname (DNS)
L' uso delle librerie di Berkley e di altre, per la risoluzione degli indirizzi, comportava
lunghi tempi di elaborazione ed in alcuni casi le risposte arrivavano fuori tempo massimo.
Per evitarlo sono state scritte delle routines alternative per la risoluzione dei DNS,
predisposte per operazioni di I/O che non comportano pause di funzionamento, e da cui si
raccolgono dati nell' ambito del loop di I/O principale del server.
8.11.2 Lettura veloce dell' Username (Ident)
Tutte le numerose librerie di identificazione che ci sono a disposizione, adatte ad essere
incluse ed adoperate all' interno di altri programmi, hanno causato inconvenienti legati al
fatto che operano in maniere sincrona, causando ritardi notevoli e frequenti. Ancora una
volta la soluzione e' stata quella di scrivere degli insiemi di routines capaci di cooperare
in maniera efficiente con il resto del software dei servers usando funzioni di I/O che non
comportano pause di funzionamento.
8.12 File di configurazione
Per fornire un modo flessibile per configurare e far funzionare il programma server, e'
auspicabile l' impiego di un file di configurazione che contenga istruzioni per il server
sugli aspetti seguenti:
* da quali hosts accettare connessioni da client;
* quali hosts autorizzare a connettersi come servers;
* a hosts possa connettersi (sia in modo attivo che passivo);
* informazioni sulla collocazione del server (per esempio: universita',
citta'/stato, azienda);
* chi sono i responsabili per quel server ed un indirizzo e-mail dove possano essere
contattati;
* hostname e parola d ordine per quei clients ai quali si desidera che sia dato accesso ai
comandi riservati agli operatori.
Nello specificare gli hostname, sia il domain name (composto da caratteri alfabetici) sia
l'uso della 'notazione numerica (127.0.0.1) dovrebbero essere accettati. Deve essere
possibile specificare la parola d ordine che deve essere usata / accettata per tutte le
connessioni in entrata ed in uscita (malgrado le uniche connessioni in uscita siano quelle
verso altri server).
La lista precedente e' il minimo richiesto per un server che desideri fare una connessione
con un altro server. Altre voci che potrebbero essere utili sono:
* quali servers altri servers possono introdurre;
* profondita' permessa ad una ramificazione del server;
* l'orario durante il quale i clients si possono connettere.
8.12.1 Permettere ai clients di connettersi
Il server dovrebbe usare qualcosa come una 'lista di controllo di accesso' (contenuta nel
file di configurazione oppure altrove) che venga letta all'accensione ed usata per decidere
quali hosts possano usare i clients per connettersi.
Sia la dichiarazione 'deny' (negato) che 'allow' (permesso) dovrebbero essere implementate
per fornire la flessibilita' necessaria per il controllo di accesso degli hosts.
8.12.2 Operatori
Concedere i privilegi di operatore ad una persona che distruttiva, puo' avere conseguenze
gravi per il buon funzionamento della rete IRC, proprio a causa dei poteri che a quella
persona vengono attribuiti. Cosi l'acquisizione di questi poteri non dovrebbe essere cosa
facile. La configurazione corrente richiede l'uso di due parole d ordine, sebbene una di
esse sia di solito facilmente intuibile. Se si memorizzano le parole d ordine per gli
operatori nei files di configurazione e' consigliabile codificarle ed immagazzinarle in un
formato criptato (per esempio usando il crypt(3) di Unix) per prevenire facili ruberie.
8.12.3 Permettere ai servers di connettersi
L' interconnessione di servers non e' una cosa banale: una cattiva connessione puo' avere
una grande influenza sull' efficienza di IRC: cosi ogni server dovrebbe avere una lista di
servers ai quali possa collegarsi, e di servers che possono collegarsi con lui. Per nessuna
ragione o circostanza un server dovrebbe permettere ad un arbitrario host di connettersi
come server. In aggiunta alla lista di servers che possono e non possono connettersi, il
file di configurazione dovrebbe anche contenere la parola d ordine ed altre caratteristiche
di quel link.
8.12.4 Administrivia
Per fornire delle risposte valide ed accurate al comando ADMIN ( si veda la sezione 4.3.7),
il server dovrebbe trovare i relativi dettagli nel file di configurazione.
8.13 Associazione ai Canali
Il server corrente permette ad ogni utente locale registrato di associarsi ad un numero
massimo di 10 canali. Non c' e' limite imposto ad utenti non locali, cosi che il server
rimane (ragionevolmente) coerente con tutti gli altri per quanto riguarda l' associazione ai
canali.
9. PROBLEMI CORRENTI
C' e' un certo numero di problemi gia' rilevati su questo protocollo, che si spera possano
essere risolti in un prossimo futuro riscrivendo il software. Attualmente sono in corso
tentativi per trovare delle soluzioni efficienti per questi problemi.
9.1 Adattamento a situazioni di dimensioni rilevanti.
E' riconosciuto ampiamente che questo protocollo non si adatta sufficientemente bene quando
opera su larga scala. Il maggior problema viene dalla necessita' che tutti i servers
sappiano di tutti gli altri servers ed utenti e che le informazioni che li riguardano siano
aggiornate non appena subiscono cambiamenti. E' inoltre desiderabile tenere basso il numero
dei servers, cosi' che la lunghezza del percorso tra due punti sia la piu' breve
[Evidentemente in termini di numero di nodi intermedi. - Nota del Revisore] e che l' albero
della rete il piu' ramificato possibile.
9.2 Etichette
L' attuale protocollo IRC prevede tre tipi di etichette: il nick, il none del canale ed il
nome del server. Ognuno di questi tipi ha il suo ambito di validita' specifico e non sono
permessi duplicati all'interno di quell' ambito. Attualmente e' possibile per gli utenti
scegliere un etichetta in ognuno dei tre ambiti, con la possibilita' di creare collisioni.
E' chiaro a molti che questo problema pone la necessita' di una revisione, con un piano di
nomi unici che non collidano, per canali e nicks. Altrettanto desiderabile appare una
soluzione che permetta un organizzazione ad albero ciclico per la rete.
9.2.1 Nicks
L'idea dei nicks su IRC e' molto conveniente da usare per gli utenti che parlano gli uni con
gli altri fuori da un canale, ma c' e' solamente uno spazio finito per i nicks come ci si
poteva tranquillamente aspettare, non e' inconsueto che piu' persone vogliano usare lo
stesso nick. Se un medesimo nickname viene scelto da due persone che usano questo
protocollo, o una delle due non riuscira' nel suo intento, oppure tutte e due saranno
rimosse con l'uso di KILL (4.6.1).
9.2.2 Canali
L' attuale organizzazione dei canali richiede che tutti i servers siano a conoscenza di
tutti i canali, dei loro membri e delle loro proprieta'. Otre al non perfetto adattamento
alle varie condizioni dimensionali della rete, anche la questione della privacy costituisce
un problema preoccupante. Una collisone di canali viene trattata come un evento inclusivo
(entrambe le persone che creano un canale sono considerate membri di esso) piuttosto che
come un evento esclusivo, del tipo di quello usato per risolvere la collisione fra nicks.
9.2.3 Servers
Sebbene il numero dei servers sia di solito piccolo, se rapportato al numero di utenti e di
canali, devono pero essere conosciuti globalmente, o separatamente uno per uno oppure
compresi dentro uno schema (mask).
9.3 Algoritmi
In qualche circostanza, nel software per il server, non e' stato possibile evitare gli
algoritmi di ordine N^2 quali il controllo della lista di canali di un insieme di clients.
Nell' attuale versione del server non sono compresi controlli sulla coerenza dei database:
ogni server presume che il suo vicino sia corretto. Questo spalanca le porte a molti
problemi se un server che si connette ha dei bugs oppure introduce contraddizioni nella rete
esistente.
A causa della mancanza di garanzia dell' unicita' per le etichette interne e globali, si
danno molto spesso dei problemi di coordinamento temporale (race condition). Queste
condizioni hanno generalmente origine dal fatto che i messaggi impiegano del tempo per
percorrere la rete IRC ed avere effetto su di essa. Anche se si cambia scegliendo un sistema
unico di etichette, rimane aperto il problema inerente i comandi relativi ai canali che
vengono perduti.
10. Supporto e disponibilita'
Mailing lists per discussioni relative a IRC:
Protocollo futuro: ircd-three-request@eff.org
Discussione generale: operlist-request@eff.org
Implementazioni software:
cs.bu.edu:/irc
nic.funet.fi:/pub/irc
coombs.anu.edu.au:/pub/irc
Newsgroup: alt.irc
11 CONSIDERAZIONI SULLA SICUREZZA
La sicurezza e' discussa nelle sezioni 4.1, 4.1.1, 4.1.3, 5.5, e 7.
12. INDIRIZZI DEGLI AUTORI
Jarkko Oikarinen Darren Reed
Tuirantie 17 as 9 4 Pateman Street
90500 OULU Watsonia, Victoria 3087
FINLE Australia
Email: jto@tolsun.oulu.fi Email: alon@coombs.anu.edu.au
Note (redatte da
Francesco Mantineo):
(1) - Ci si riferisce a 4 anni trascorsi all'epoca del rilascio della RFC originale: l' eta'
al momento attuale (1977) di IRC supera gli 8 anni.
(2) - Questo documento non descrive esattamente il protocollo IRC attualmente utilizzato
(1977), ma non risultano esistere documenti successivi e piu' aggiornati cosi' ampi e
comprensivi.
(3) - Sembra che le attuali versioni dei server non permettano comunque l'accesso a piu' di
10 canali, ma esistono diverse versioni sulla stessa rete che si comportano in modo diverso.
(4) - "Socket", come "file", non si traduce in italiano, di solito. In
parole molto povere, un socket e' un "file di rete" cioe' corrisponde ad un canale
e non a dei dati su una memoria di massa, ma puo' essere letto e scritto come un file.
(5) - Alle tre precedenti dovrebbe essere aggiunta la seguente condizione:
4. se il canale e' +l il numero massimo di utenti sul canale non deve essere raggiunto (o
superato).
(6) - Dovrebbe (anzi di solito lo e' ) essere data anche la RPL_NAMEREPLY.
(7) - Non sembra facile poter pensare ad una trasformazione di IRC senza nicknames.
(8) - Questi modi ormai non riflettono piu' quelli attualmente disponibili nelle attuali
versioni usate su IRCNet.
(9) - Anche questi modi non corrispondono esattamente a quelli attualmente in uso su IRCNet:
tanto per fare un esempio, non esiste piu' il modo "s" ed esiste il famigerato
modo "r".
(10) - L'estensione del comando non dovrebbe piu' essere possibile con le nuove versioni del
server IRCNet.
(11) - I servers attuali rispondono ad un numero abbastanza maggiore di richieste, ad
esempio: "/stats z", "/stats d", "/stats t".
(12) - Attualmente anche un operatore puo' vedere gli utenti connessi solo al suo server.
Nelle precedenti versioni, gli operatori potevano effettivamente vedere gli utenti anche su
altri servers.
(13) - Il /whois si comporta in maniera leggermente differente in realta': vengono
visualizzate tutte le informazioni solo se il nick richiesto e' sullo stesso server di chi
esegue il comando, altrimenti vengono visualizzate solo le informazioni generali (nick,
hostname e servername).
(14) - Il commando SUMMON e' ormai disabilitato quasi su ogni server.
(15) - Per ottenere un elenco completo delle risposte numeriche e del loro significato e'
opportuno fare riferimento direttamente ai sorgenti della versione del programma server alla
quale si e' interessati. - Se la memoria non mi abbandona, si trovano nel file
"numerics.h".
(16) - La versione attuale e' la 2.9 e la 2.9.2p2 quella maggiormente usata. (Giugno '97)
|
