A.1. RFC1459 - Il protocollo IRC
| Network Working Group |
J. Oikarinen |
| Request for commentts: 1459 |
D. Reed |
| May 1993 |
|
Protocollo per l'Internet Relay Chat
Posizione di questo
memorandum
Questo memorandum delinea un Protocollo
Sperimentale per la comunità di Internet. Discussioni e suggerimenti,
per il miglioramento dello stesso, sono graditi. Si prega di fare
riferimento all'edizione corrente del "IAB Official Protocol
Standards" per la standardizzazione
e la definizione della posizione di questo protocollo. La distribuzione
di questo memorandum è libera.
Riassunto
Il protocollo IRC fu sviluppato durante gli ultimi 4 anni(1) da quando fu implementato per la prima
volta come mezzo in grado di permettere agli utenti di parlare
tra loro su un BBS (BBS: Bullettin Board System. E'
un sistema a gestione privata al quale ci si può collegare tramite
linea telefonica e che mette a disposizione programmi, dati, aree
di messaggi etc.. nell'ambito della cosiddetta telematica amatoriale.-
N.d.T.). Attualmente esso sostiene un
network mondiale di server e clients, e si sta espandendo per
far fronte alla crescente espansione dell'utenza. Negli ultimi
2 anni, il numero medio di utenti connessi
al network IRC principale si è decuplicato. Il protocollo IRC
è un protocollo, basato su stringhe di testo, il cui interlocutore
più semplice consiste in un programma capace di stabilire una
connessione col server.
Indice
Index
1. INTRODUZIONE
Il protocollo IRC (Internet Relay Chat) è stato progettato e costruito,
con un lavoro durato diversi anni, per la realizzazione di scambi di messaggi
scritti in tempo reale. Questo documento descrive il protocollo di IRC attualmente
in uso. (2) Il protocollo IRC è stato
sviluppato su un sistema che usa il protocollo di rete TCP/IP, senza nessuna
necessità, tuttavia, che questa rimanga il suo solo ambito di utilizzo. L'IRC
stesso è un sistema di teleconferenza che (mediante l'uso del modello client-server)
è stato adattato per lavorare su molte macchine di modelli diversi. Un tipico
sistema comporta un singolo processo (il server) che costituisce un punto centrale
al quale i client (o altri server) possono connettersi, realizzando i necessari
invio e distribuzione contemporanea su più utenti del messaggio ed altre funzioni.
Indice
1.1 I Servers
Il server forma la spina dorsale di IRC, fornendo un punto al quale i client
possono connettersi per parlarsi gli uni con gli altri, ed un punto di connessione
per altri server, formando così una rete IRC. L'unica configurazione di rete
permessa ai server di IRC è quella di un albero [vedi Fig. 1] dove ogni
server agisce come nodo centrale per il resto della rete che vede.
[ Server 15 ] [ Server 13 ] [ Server 14]
/ \ /
/ \ /
[ Server 11 ] ------ [ Server 1 ] [ Server 12]
/ \ /
/ \ /
[ Server 2 ] [ Server 3 ]
/ \ \
/ \ \
[ Server 4 ] [ Server 5 ] [ Server 6 ]
/ | \ /
/ | \ /
/ | \____ /
/ | \ /
[ Server 7 ] [ Server 8 ] [ Server 9 ] [ Server 10 ]
:
[ etc. ]
:
[Fig. 1. Configurazione di una rete di server IRC]
Indice
1.2 I Clients
Si definisce client qualsiasi cosa connessa ad un server che
non sia un altro server. Ogni client si distingue dagli altri
client per un nickname unico, della lunghezza massima di nove
(9) caratteri. Si vedano le regole grammaticali del protocollo
per sapere quali caratteri si possono e quali non si possono usare
in un nickname. In aggiunta al nickname, tutti i server devono
avere le seguenti informazioni su ogni client: il vero nome della
macchina sulla quale il programma client viene
eseguito, il nome dell'utente del client di quella macchina, ed
il server al quale il client è connesso.
Indice
1.2.1 Gli Operatori
Per far sì che il lavoro di rete venga
svolto in maniera sufficientemente ordinata, si permette ad una
determinata classe di client (operatori) di compiere delle funzioni
di manutenzione generale sulla rete. Malgrado
i poteri attribuiti ad un operatore possano essere considerati
"pericolosi", essi sono tuttavia necessari. Gli operatori
dovrebbero essere in grado di compiere operazioni di base sulla
rete, quali lo sconnettere e il riconnettere servers, per prevenire
di un routing non efficiente sulla rete. Prendendo atto di questa
esigenza, il protocollo qui esposto prevede per gli operatori
solo la capacità di compiere quelle operazioni. Si vedano le sezioni
4.1.7 (Messaggio Server Quit) e 4.3.5 (Messaggio Connect).
Uno dei più controversi, tra i poteri attribuiti agli operatori
è la possibilità di rimuovere "con la forza"
un utente dalla rete: gli operatori sono in grado, per esempio,
di chiudere la connessione tra un qualsiasi client e il server.
La giustificazione per questo è cosa critica, dal momento che
un abuso di questa possibilità risulta sempre fastidioso e distruttivo. Per altri dettagli
sul'argomento si veda la sezione 4.6.1 (Messaggio KILL).
Indice
1.3 I Canali
Un canale è un gruppo, dotato di nome, di uno o più client dove
tutti i membri del gruppo ricevono i messaggi indirizzati a quel
canale. Il canale è automaticamente creato quando il primo client
vi si collega, e cessa di esistere quando l'ultimo client lo lascia.
Durante il periodo di esistenza del canale
ogni client può riferirsi a quel canale usando il nome dello stesso.
I nomi dei canali sono stringhe (che iniziano con un "&"
oppure con un "#") lunghe fino a 200 caratteri. A parte
la necessità che il primo carattere sia "&" oppure
"#", l'unica restrizione che sussiste per il nome del
canale è che non contenga alcuno spazio (" "), un control
G (^G o ASCII 7), o una virgola ("," la quale è considerata dal protocollo come separatore
tra gli elementi di una lista).
Ci sono due tipi di canali ammessi da questo protocollo. Uno è
un canale assegnato che è conosciuto da tutti i server che sono
connessi alla rete. Questi canali sono contrassegnati dall'
avere come primo carattere (un #, gli altri sono i cosiddetti
canali locali, il cui nome è preceduto da un carattere & e
che) si distinguono per essere accessibili solo ai client del
server ove il canale esiste. [Ndr - Qui probabilmente il testo
originale a nostra disposizione omette parte del periodo, ma,
dal contesto, si può tentare una interpretazione
che abbiamo inserito tra parentesi tonde] Questi canali sono distinti
dal carattere iniziale "&". Sono disponibili inoltre
diversi modi disponibili per alterare le caratteristiche dei singoli
canali. Si veda la sezione 4.2.3 (Messaggio MODE) per maggiori dettagli
sull'argomento.
Per creare un nuovo canale o entrare a far parte di un canale
già esistente, un utente entrare (JOIN) nel canale. Se il canale
non preesiste al join, il canale viene creato ed il creatore del canale
diventa operatore su quel canale. Se invece il canale già esiste,
la richiesta di join al canale viene onorata o meno dipendentemente dai "modes" in vigore
al momento su quel canale. Per esempio se si tratta di un canale
ad invito (+i), la richiesta verrà accolta solo se si è stati invitati da qualcuno.
Secondo il protocollo, un utente può accedere a diversi canali
contemporaneamente, ma si raccomanda di non superare il limite
di dieci (10) canali, un confine ampio, sia per gli esperti che
per i novizi. Si veda la sezione 8.13 per maggiori informazioni su questo
argomento. (3) Se qualche ramo della rete IRC si spezza
a causa di uno split (perdita del collegamento) tra due servers,
del canale, su ognuno dei due versanti della rete divisi dal punto
di interruzione, faranno parte solamente
quei client che sono connessi al server sul rispettivo versante
dello split, cessando di farne parte su quello opposto allo split.
Quando il collegamento è ripristinato,
i servers, di nuovo connessi, si comunicano l'un l'altro la propria
lista dei client presenti sul canale i "modes" di quel
canale. Se il canale esiste su tutti e due
i versanti i JOIN e i MODE vengono interpretati in una maniera
inclusiva cosicchè i due versanti della nuova connessione si troveranno
in accordo su quali client sono nel canale e qual'è ale.
Indice
1.3.1 Gli Operatori di canale
L' operatore di canale (detto anche
"chop" o "chanop") su un dato canale può essere
considerato come "proprietario" di quel canale. A causa
di questo loro stato, gli operatori di canale sono dotati di certi
poteri che li mettono in condizione di mantenere controllo e una
forma di pulizia sul loro canale. Come proprietario di un canale,
ad un operatore non si richiede di render ragione per le sue azioni,
tuttavia se le sue azioni sono particolarmente antisociali o costituiscono
in qualche modo abuso, potrebbe essere ragionevole chiedere ad
un operatore IRC di intervenire,oppure che gli utenti semplicemente escano e formino un
loro canale.
I soli comandi che possono essere usati dagli operatori di canale
sono:
KICK - Espelle un client
dal canale
MODE - Cambia il mode del
canale
INVITE - Invita un client ad un canale ad invito (mode +i)
TOPIC - Cambia il topic del canale in mode +t
Un operatore di canale è identificato dal simbolo
'@' posto a fianco del suo nickname ogniqualvolta esso è associato
con un canale (per esempio risponde ai comandi NAMES, WHO e WHOIS).
2. SPECIFICHE IRC
2.1 Generalità
Il protocollo qui descritto realizza sia connessioni server-server
che connessioni client-server. Va detto, comunque,
che ci sono più restrizioni nelle connessioni client-server (che
sono considerate inattendibili) che in quelle server-server.
Indice
2.2 Codici dei caratteri
Nessun set particolare di caratteri è specificato. Il protocollo
è basato su un sistema di codici composti da
otto (8) bits, vale a dire un ottetto (byte). Ogni messaggio può
essere composto da un numero qualsiasi
di questi ottetti, sebbene i valori di alcuni ottetti vengano
usati come codici di controllo, che svolgono il ruolo di delimitatori
dei messaggi. Indipendentemente dal fatto di essere un protocollo
a 8 bits, i delimitatori dei messaggi e i comandi sono organizzati
in maniera tale da rendere il protocollo maggiormente utilizzabile
da terminali USASCII e da connessioni telnet.
A causa dell'origine scandinava di IRC,
i caratteri {} e | sono considerati essere l'equivalente minuscolo
dei caratteri [] e \. Questo problema crea una situazione critica
quando si tratta di determinare l'equivalenza di due nickname.
Indice
2.3 Messaggi
I server e i client si scambiano messaggi che possono generare
o meno una risposta. Se il messaggio contiene un comando valido, come descritto nelle prossime
sezioni, il client dovrebbe aspettarsi una risposta coerente con
le specifiche, ma non è consigliabile che attende la replica del
server per un tempo illimitato, poichè le comunicazioni client-server
e server-server sono di natura essenzialmente asincrona.
Ogni messaggio IRC può essere consistere fondamentalmente di tre
parti: il prefisso (facoltativo), il comando, ed i parametri del
comando (ve ne possono essere fino a 15). Il prefisso, il comando
e tutti i parametri sono separati da uno (o più) caratteri "spazio"
(ASCII: 0x20).
La presenza di un prefisso è indicata con un singolo carattere
due punti (":"), (ASCII: 0x3b),
in prima posizione. Non ci devono essere lacune
(spazi bianchi) tra i due punti ed il prefisso.
Il prefisso è usato dai server per specificare la vera
origine del messaggio. Se manca il prefisso, si assume che il
messaggio abbia avuto origine dalla connessione sulla quale
è stato ricevuto. Non è necessario che un client premetta un prefisso
quando inviano un messaggio: se usano un prefisso, l'unico prefisso
valido è il nickname registrato ed associato con quel client.
Se la sorgente identificata dal prefisso
non può essere trovata nel database interno del server, oppure
se la sorgente è registrata su un link differente da quello da
cui arriva il messaggio, il server deve tacitamente ignorare il
messaggio.
Il comando deve essere o un comando IRC valido, oppure deve essere
un numero di tre (3) cifre rappresentato in codice ASCII. I messaggi
IRC sono linee di caratteri che terminano sempre con una coppia
CR-LF (Ritorno a capo - Salto di riga), e non devono eccedere
i 512 caratteri in lunghezza, compresi tutti i caratteri inclusi
i caratteri di coda CR-LF. Perciò
il massimo numero di caratteri permesso per ogni riga di comando
con gli eventuali parametri è di 510. Non c' è la possibilità
di usare linee di continuazione per i messaggi. Si veda la sezione
7 per maggiori informazioni sulle implementazioni correnti.
Indice
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 è scomposto ed analizzato nei componenti:
(prefisso), (comando) e lista di parametri uniti fra loro da componenti
<intermedi> o <iniziali>.
Per tanto la rappresentazione BNF [Ndr - Backus Normal Form] di
questo assetto è:
<messaggio> ::=
[':' <prefisso> <SPAZIO> ] <Comando> <parametri> <crlf>
<prefisso> ::=
<nome-del-server> | <nick> ['!' <utente> ] [ '@' <macchina> ]
<Commando> ::=
<lettera> { <lettera> } | <numero>
<numero> <numero>
<SPAZIO> ::=
' ' { ' ' }
<parametri> ::=
<SPAZIO> [ ':'
<iniziali> | <intermedi> <parametri> ]
<intermedi> ::=
< Qualsiasi sequenza *non vuota* di ottetti che non includa i caratteri SPAZIO, NUL (zero
binario), CR, LF e il cui primo carattere non può essere ':'>
<iniziali> ::=
<Qualsiasi sequenza di ottetti, anche *vuota*, che non includa NUL o CR o LF>
<crlf> ::=
CR LFG
Note:
1. <SPAZIO> consiste solo del(i)
carattere(i) SPAZIO (0x20). Nota bene che la TABULAZIONE, e tutti
gli altri caratteri di controllo sono considerati SPAZI NON BIANCHI.
2. Dopo aver estratto la lista di parametri, tutti i parametri
sono equivalenti, non ha importanza che essi si possano associare con <intermedi> o <iniziali>.
<Iniziali> è solamente un espediente sintattico per permettere
lo SPAZIO tra i parametri.
3. Il fatto che CR e LF non possono
apparire nel contesto dei parametri è solo un fatto dipendente
dalla modalità di delimitazione del comando. Questo potrebbe cambiare
in futuro.
4. Il carattere NUL non ha significato
speciale nella composizione dei messaggi, e, in linea di principio,
potrebbe essere parte di un parametro, causando però delle
difficoltà nel normale trattamento delle stringhe in linguaggio
"C". Questo è l' unico motivo
per cui non è permesso l'uso del carattere NUL all'interno dei
messaggi.
5. L'ultimo parametro può essere una stringa vuota.
6. L'uso del prefisso esteso (['!' <user> ] ['@' <host>
]) non deve essere usato nelle comunicazioni server-server, ed
è previsto solo nell'ambito della comunicazione server- client
in modo da fornire ai client maggiori
informazioni utili riguardo la provenienza del messaggio, senza
necessità di ulteriori domande.
Gran parte dei messaggi previsti dal
protocollo specificano semantica e sintassi
addizionali, dettata dalla loro posizione nella lista, per le
stringhe dei parametri. Per esempio, molti comandi dei server
assumono che il primo parametro dopo il comando è una lista di
obbiettivi, così organizzata:
<obbiettivo> ::=
<a> [ ","<obbiettivo> ]
<a> ::=
<canale> | <utente> '@' <nome-del-server> | <nick> | <maschera>
<channel> ::=
('#' | '&') <stringa-di-caratteri>
<nome-del-server> ::=
<macchina>
<macchina> ::=
si veda l' RFC 952 [DNS:4]
per dettagli sui nomi-macchina permessi
<nick> ::=
<lettera> { <lettera> | <numero>
| <carattere-speciale> }
<maschera> ::=<
('#' | '$') <stringa-di-caratteri
(contenente eventuali "*" e "?")>
<stringa-di-caratteri> ::=
<qualsiasi sequenza di ottetti tranne SPACE, BELL, NUL, CR, LF e virgola (',')>
Ulteriori elementi sintattici
dei parametri sono:
<utente> ::=
<nonbianco> { <nonbianco> }
<lettera> ::=
'a' ... 'z' | 'a'
... 'Z'
<numero> ::=
'0' ... '9'
<speciale> ::=
'-' | '[' | ']' |
'\' | '`' | '^' | '{' | '}'
<nonbianco> ::=
<ogni codice 8bit tranne SPACE (0x20), NUL (0x0), CR (0xd) e LF(0xa)>
Indice
2.4 Risposte numeriche
La maggior parte dei messaggi inviati al server generano una risposta di qualche sorta. La risposta più
frequente è una risposta numerica, usata sia per risposte normali
che di errore. La risposta numerica deve essere inviata come
un messaggio consistente del prefisso del mittente, le tre cifre
numeriche e la destinazione della risposta. Non è permesso che
una risposta numerica abbia origine da un client; qualsiasi messaggio
di questo genere ricevuto da un server viene tacitamente ignorato. Sotto tutti gli altri aspetti
la risposta numerica è simile ad un normale messaggio, con la
sola differenza che la parola-chiave è formata da tre cifre numeriche
invece che da una stringa di lettere. Una lista delle possibili
risposte è contenuta nella sezione 6.
Indice
3. CONCETTI DI IRC
Questa sezione è dedicata all' esposizione dei concetti su cui si basa l' organizzazione
del protocollo IRC e come le implementazioni attualmente in uso
inoltrino le differenti categorie di messaggi.
1--\
A D---4
2--/ \ /
B----C
/ \
3 E
Servers: A, B, C, D, E Clients: 1, 2, 3, 4
[ Fig. 2. Esempio di una rete IRC di piccole dimensioni]
3.1 Comunicazione uno a uno
La comunicazione uno a uno è realizzata di solito dai clients, dal momento che
la maggior parte del traffico server a server non è il risultato
di server che parlino esclusivamente tra loro. Per dare ai client
la possibilità di parlare loro, è necessario che tutti i server
siano in grado di inviare un messaggio in una direzione precisa
lungo la struttura ad albero della rete, in modo da poter raggiungere
qualsiasi client. Il percorso di un messaggio inviato è quello
più corto tra due punti qualsiasi della struttura.
Gli esempi che seguono fanno riferimento alla Figura 2.
Esempio 1 :
Un messaggio tra i client 1 e 2 è visto solo
dal server A, il quale lo invia direttamente al
client 2.
Esempio 2 :
Un messaggio tra i client 1 e 3 è visto dai
server A e B, e dal client 3. A nessun
altro server o client è permesso di vedere il messaggio.
Esempio 3 :
Un messaggio tra i client 2 e 4 è visto dai
server A, B, C e D, e solamente dal client 4.
Indice
3.2 Uno a molti
Lo scopo principale di IRC è di realizzare
un luogo pubblico di incontro nell' ambito del quale sia possibile,
in maniera semplice ed efficiente, lo scambio di messaggi fra
più persone (conversazione uno a molti).
A questo proposito IRC offre diversi mezzi, ognuno dei quali è
orientato al raggiungimento di uno specifico scopo.
Indice
3.2.1 Ad una lista
Il tipo di conversazione uno-a-molti meno efficiente consiste
nel parlare, attraverso i clients, ad una "lista" di utenti. Come questo avvenga è piuttosto banale: il client
fornisce una lista di destinazioni alle quali il messaggio deve
essere inviato ed il server lo "moltiplica", inviando
delle copie separate del messaggio ad ogni destinazione data.
Questo sistema non è efficiente come quello della conversazione
uno ad un gruppo, dal momento che la lista di destinazione viene
considerata come composta da tante singole destinazioni e l'invio
dei messaggi avviene senza controllare che non vengano inviati
dei duplicati lungo i possibili percorsi.
Indice
3.2.2 Ad un gruppo (canale)
In IRC il canale ha il ruolo equivalente
a quello di un gruppo ad invio multiplo; la sua esistenza è dinamica
(sussistendo e/o cessando in funzione del fatto che gli utenti
siano presenti o lascino il canale) e la conversazione in corso
in un canale è inviata solo a quei server cui siano
collegati utenti di un canale dato. Se
ci sono più utenti sullo stesso server per lo stesso canale, il
messaggio è inoltrato solamente una volta a quel server e poi
inviato ad ognuno dei client del canale. Questa operazione viene
poi ripetuta per ogni combinazione client-server finchè il messaggio
originale non sia stato diffuso ed abbia raggiunto ogni membro
del canale.
I seguenti esempi fanno riferimento alla figura 2.
Esempio 4 :
Ogni canale con 1 solo client presente. I
messaggi al canale vanno al server e da nessun
altra parte.
Esempio 5 :
2 client in un canale. Tutti i messaggi attraversano
un percorso come se fossero messaggi privati tra i due client
a prescindere dal canale.
Esempio 6 :
Client 1, 2 e 3 dentro un canale.
Tutti i messaggi al canale sono inviati a tutti i client e solo
a quei server che devono essere attraversati dal messaggio come
se esso fosse un messaggio privato ad un singolo client. Se
il client 1 manda un messaggio, esso arriva al client 2 e poi,
tramite il server B, al client 3.
Indice
3.2.3 Ad uno schema macchina-utente/server
Per fornire gli operatori di IRC di
un qualche meccanismo per inviare messaggi ad un novero consistente
di utenti, i messaggi stessi vengono corredati di "schemi
macchina-utente e server". Questi messaggi sono inviati agli
utenti per i quali le informazioni sulla macchina o sul server
corrispondono a quelle dello schema. I messaggi vengono
inviati solo alla locazione ove si trovano gli tenti, in un modo
simile a quello usato per i canali.
Indice
3.3 Uno a tutti
Il tipo di messaggio uno a tutti è meglio denotato come un messaggio
diffuso, inviato a tutti i client o/e a tutti i servers. In una
rete di server e utenti di grandi dimensioni, un messaggio singolo
può dar luogo ad un rilevante volume di traffico, nel momento
in cui viene inviato attraverso la rete, per poter raggiungere
tutte le destinazioni desiderate.
Per alcuni messaggi non c' è altra soluzione che diffonderli a
tutti i servers, affinchè le informazioni di stato contenute da
ogni server siano ragionevolmente coerenti tra i server stessi.
Indice
3.3.1 Client a Client
Non c' è alcuna categoria di messaggi per la
quale, partendo da un messaggio singolo, derivi un messaggio
che sia inviato ad ogni altro client.
Indice
3.3.2 Client a
Server
La maggior parte dei comandi che risultano
nello scambio di informazioni di stato (quali appartenenza ad
un canale, mode del canale, status dell' utente ecc.) deve, per
default, essere inviata a tutti i server, e questa distribuzione
non dovrebbe essere cambiata dal client.
Indice
3.3.3 Server a Server.
Se la maggior parte dei messaggi tra
due server viene distribuita a tutti
gli "altri" server, questo è in effetti richiesto solamente
per ogni messaggio che abbia effetto su un utente, un canale o
un server.
Dal momento che queste sono le voci base che si trovano in IRC,
la quasi totalità dei messaggi originati da un server vengono
distribuiti a tutti gli altri server connessi.
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 è stato possibile trovare il parametro <server>.
Il server non deve dare ulteriori risposte
per questo comando.
Il server, al quale un client è 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 validità, 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
è essenziale includere il nome del mittente originario del messaggio,
così che i server remoti possano mandare una risposta attraverso
il percorso corretto.
Indice
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 è necessario un comando "PASS" perchè 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. è
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 è il seguente:
1. messaggio Pass
2. messaggio Nick
3. messaggio User
Indice
4.1.1 Messaggio Password
Comando: PASS
Parametri: <password>
Il comando PASS è usato per stabilire una parola d'ordine per
la connessione. La parola d'ordine può 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
può essere cambiato una volta registrato.
Risposte numeriche:
ERR_NEEDMOREPARAMS (Errore_necessitano
più parametri) ERR_ALREADYREGISTRED (Errore_già registrato)
Esempio:
PASS parola_d_ordine_qui
Indice
4.1.2 Messaggio Nickname
Comando: NICK
Parametri: <nickname> [ <hopcount> ]
Il messaggio NICK è usato per dare un nickname ad un utente o
per cambiare quello che aveva in precedenza. Il parametro <hopcount> è usato solamente
dai server 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 è già a conoscenza
di un identico nickname per un altro client, si verifica una collisione
di nicknames. Il risultato di una collisione di nickname è 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 già presente da un client che è connesso
direttamente, può inviare al client locale un messaggio di ERR_NICKCOLLISION, ignorare il comando NICK, e non generare
alcun kill.
Risposte numeriche:
ERR_NONICKNAMEGIVEN (Errore_non è stato dato
nessun nickname)
ERR_ERRONEUSNICKNAME (Errore_nickname errato)
ERR_NICKNAMEINUSE (Errore_nickname
già in uso)
ERR_NICKCOLLISION (Errore_collisone
di nicknames)
Esempi:
NICK Wiz ; Inserimento nuovo nick "Wiz".
:WiZ NICK Kilroy ; WiZ cambia il suo nickname in Kilroy.
Indice
4.1.3 Messaggio User, utente
Comando: USER
Parametri: <nome_utente> <nome_macchina> <nome_server>
<nome_reale>
Il messaggio USER è 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 è registrato solamente dopo che i comandi
USER e NICK sono stati ricevuti da un client.
Tra i server 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 nome_reale deve
essere l'ultimo, perchè può contenere dei caratteri spazio, e
deve essere preceduto dal carattere due punti (':')
per far sì che sia riconosciuto.
Dal momento che per l'utente è facile mentire sul suo nome-utente
facendo affidamento unicamente sul messaggio USER, è 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 sarà quello proveniente
dalla risposta dell' "Identity Server".
Risposte numeriche:
ERR_NEEDMOREPARAMS (Errore_necessitano più parametri)
ERR_ALREADYREGISTRED (Errore_già 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 server con il nickname al quale appartiene il comando USER.
Indice
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'è un server.
Questo messaggio viene anche usato per passare i dati del server
a tutta la rete. Quando un nuovo server
è connesso alla rete, le informazioni che lo riguardano sono inviate
a tutto il network. <numero-tratte> viene
usato per dare a tutti i server alcune informazioni interne sulla
distanza cui si trova ciascun server. Con una lista completa dei
server, sarebbe possibile ricostruire una mappa completa della
configurazione dei collegamenti fra i server, 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 già 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 proprietà utili che lo rendono, in
questo caso, vantaggioso. Se un messaggio SERVER viene
analizzato e cerca di introdurre un server che è già noto al server
ricevente, la connessione dalla quale arriva il messaggio deve
essere chiusa (se si seguono le procedure corrette), in quanto
si è formato un doppio percorso per quel server e la natura aciclica
della rete IRC risulta compromessa.
Risposta Numerica:
ERR_ALREADYREGISTRED (Errore_già 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 [..]
è il nome della macchina sulla quale è attivo test.oulu.fi.
:tolsun.oulu.fi SERVER csd.bu.edu 5 :BU Central Server ; Il server
tolsun.oulu.fi è il nostro collegamento per csd.bu.edu che si
trova a 5 tratte di distanza.
Indice
4.1.5 Messaggio Oper, Operatore
Comando: OPER
Parametri: <utente> <parola_d_ordine>
Il messaggio OPER è usato da un utente normale per ottenere i
privilegi di operatore. La combinazione di <utente> e <parola_d_ordine>
è 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 è solamente un messaggio client-server.
Risposte numeriche:
ERR_NEEDMOREPARAMS (Errore_necessitano più parametri)
RPL_YOUREOPER (risposta_sei
già operatore)
ERR_NOOPERHOST (errore_non ci sono
O: line per l'utente specificato)
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.
Indice
4.1.6
Messaggio
Quit (abbandonare)
Comando: QUIT
Parametri: [<Messaggio di cessazione>]
La sessione di un client è 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", verrà
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 server coinvolti separati da uno spazio. Il primo nome
è quello del server che è 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 (Andato a pranzo)
; Format preferibile del messaggio.
Indice
4.1.7
Messaggio
Server Quit
Comando: SQUIT
Parametri: <server> <commento>
Il messaggio SQUIT viene impiegato per
rendere conto dei server 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 disponibilità 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 più sotto. Il parametro "commento"
dovrebbe essere fornito da tutti gli operatori che eseguono uno
SQUIT su un server remoto (che non è connesso cioè al server sul quale essi operano) cosicchè 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 server 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
server che sono considerati trovarsi a valle di ciascuno di questi
collegamenti. Alla stessa maniera, un messaggio QUIT deve essere
inviato a tutti gli altri server connessi al resto della rete
nell'interesse di tutti i client 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
è richiesto di informare il resto della rete che la connessione
si è 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 è 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 perchè "Server out of control" (server fuori controllo).
Indice
4.2 Operazioni
del Canale
Questo gruppo di messaggi concerne la manipolazione dei canali,
le loro proprietà (mode del canale), ed il loro contenuto (usualmente
clients).
Per una giusta realizzazione, è necessario
stabilire un numero di regole, quando i client che si trovano
agli estremi opposti della rete inviano messaggi che potrebbero
collidere fra loro. è richiesto, inoltre, che i server mantengano una traccia
storica dei nickname per assicurarsi che, ogniqualvolta un parametro
<nick> è dato, il server ne controlli la storia nel caso
sia stato cambiato di recente.
Indice
4.2.1
Messaggio
Join
Comando: JOIN
Parametri: <canale>{,<canale>}
[<chiave>{,<chiave>}]
Il comando JOIN è usato dal client per avere accesso ai messaggi
provenienti da un dato canale. La verifica della
sussistenza della condizione perchè un client sia autorizzato
o meno ad aggregarsi al canale, viene realizzata dal server al
quale il client è connesso. Tutti gli altri server aggiungono
automaticamente il client al canale quando la sua ammissione ad
un canale è notificata da altri server. Le condizioni che determinano
l'ammissione sono le seguenti:
1.
Il client deve essere invitato se il canale è ad invito
(mode +i);
2.
Il nick/nome_utente/nome_macchina del client non devono
corrispondere a ban attivi;
3.
Se è definita una parola d'ordine di
acceso, deve essere fornita la parola corretta (mode +k)
(5).
Tutto questo è discusso più 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 server 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
più 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
Indice
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 più 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".
Indice
4.2.3
Messaggio
Mode
Comando: MODE
Il comando MODE ha due scopi: permette
infatti di cambiare i MODE sia dei canali che degli utenti. La
ragione di questa scelta è che in futuro i nickname saranno obsoleti
e l'entità equivalente sarà il canale. (7)
Quando viene analizzato un comando MODE,
è essenziale che prima il messaggio venga analizzato nella sua
totalità e che, in un secondo tempo, i cambiamenti dettati dal
messaggio vengano effettuati.
Indice
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 è
a disposizione degli operatori di canale perchè possano cambiare
le caratteristiche del 'loro' canale. è richiesto inoltre che i server siano in grado di cambiare
i mode dei canali così che sia possibile creare operatori. I mode dei canali disponibili sono i seguenti:
o - dà/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 client 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 - dà/toglie la possibilità 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', è stata imposta una restrizione
di tre comandi per mode. Vale a dire, ogni combinazione di 'o'
e (Qui il testo inglese è lacunoso, ma, con ogni probabilità si
intende dire che ogni combinazione di 'o' e 'b', può contenere
al massimo tre elementi. - N.d.T.)
Indice
4.2.3.2 Mode dell'utente
Parametri: <nickname> {[+|-]|i|w|s|o}
(9)
I MODE degli utenti sono cambiamenti
che determinano come il client è visto dagli altri, oppure che
tipo di messaggi 'extra' possono essere inviati al client. Il
comando MODE per l'utente può 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 è ignorato. Non c'è alcuna
restrizione, comunque, per chiunque voglia deopparsi (usando "-o").
Risposte numeriche:
ERR_NEEDMOREPARAMS (errore_necessitano più parametri)
RPL_CHANNELMODEIS (risposta_il modo di
canale è: )
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 è: )
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 più 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.
Indice
4.2.4
Messaggio
Topic
Comando: TOPIC
Parametri: <canale> [<topic>]
Il messaggio TOPIC è usato per cambiare o prender visione del
topic di un canale. Se non è dato alcun parametro <topic> il messaggio di
ritorno sarà il topic del canale. Se invece il parametro
<topic> è presente, il topic di quel canale potrà essere
cambiato, se il mode del canale permette
questa azione.
Risposte numeriche:
ERR_NEEDMOREPARAMS (errore_necessitano più parametri)
ERR_NOTONCHANNEL (errore_non sei
sul canale)
RPL_NOTOPIC (risposta_topic
vuoto)
RPL_TOPIC (risposta_il
topic del canale è: )
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.
Indice
4.2.5
Messaggio
Names
Comando: NAMES
Parametri: [<canale>{,< canale>}]
Usando il comando NAMES gli utenti possono avere una lista di
tutti i nickname 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'è risposta di errore in caso di nome errato del canale.
Se non è 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.
Indice
4.2.6
Messaggio
List
Comando: LIST Parametri: [<canale>{,<canale>}
[<server>]]
Il messaggio LIST è usato per listare i canali ed i loro topics.
Se è 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
Index
4.2.7
Messaggio
Invite
Comando: INVITE Parametri:
<nickname> <canale>
Il messaggio INVITE usato per invitare gli utenti su un canale. Il parametro <nickname>
è il nick della persona da invitare sul canale <canale>.
Non è 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
più parametri)
ERR_NOSUCHNICK (errore_nick
inesistente)
ERR_NOTONCHANNEL (errore_non sei
sul canale)
ERR_USERONCHANNEL (errore_utente già 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
Indice
4.2.8
Messaggio
Kick
Comando: KICK
Parametri: <canale> <utente> [<commento>]
Il comando KICK può essere usato per rimuovere forzatamente un
utente da un canale. Esso lo 'scalcia fuori del canale' (PART forzato). Solo un
operatore di canale può rimuovere un utente dal canale. Ogni server
che riceva un messaggio KICK controlla se il comando sia valido
(per esempio se il mittente è un operatore), prima di rimuovere
la vittima dal canale.
Risposte numeriche:
ERR_NEEDMOREPARAMS (errore_necessitano più 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: è possibile estendere i parametri
del comando KICK come segue:
<canale>{,<canale>} <utente>{,<utente>}
[<commento>] (10)
Indice
4.3 Comandi e richieste
di informazioni al server
Il gruppo di comandi per la richiesta di informazioni
al server è stato previsto per ottenere informazioni su ogni server
connesso alla rete. Tutti i server 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 finchè 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.
Indice
4.3.1
Messaggio
Version
Comando: VERSION
Parametri: [<server>]
Il messaggio VERSION è usato per avere informazioni a proposito
della versione nel 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
è: )
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".
Indice
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 modalità di esecuzione di questo
comando dipendono fortemente dal server che risponde, tuttavia
i server debbono essere in grado di fornire le informazioni descritte
qui di seguito (o qualcosa di analogo). Una particolare richiesta
può essere denotata da una singola lettera controllata dal solo
server di destinazione (se dato come parametro <server>),
ed è invece trasmessa, ignorata ed inalterata, dai server 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 modalità diverse
da altre versioni, tutti i server dovrebbero essere in grado di
fornire una risposta valida ad una richiesta STAT, una replica
cioè, conforme ai formati di risposta comunemente usati e coerente
con lo scopo della richiesta.
Le richieste usualmente soddisfatte sono:
c - ritorna una lista di server ai quali il server può
connettersi o dai quali permette connessioni;
h - ritorna una lista di server i quali sono considerati
forzatamente "foglie" (elementi periferici) nell'albero
della rete oppure ai quali è permesso di agire come suoi punti
nodali;
i - ritorna una lista di host 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 è stabilita ogni connessione, il traffico su
quella connessione in byte 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 è stato
usato, se il conteggio è un numero diverso da zero;
o - ritorna una lista di host provenendo dai quali normali
client 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
è 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 è connessi
:Wiz STATS c eff.org ; richiesta di WiZ per informazioni sulle
linee C/N al server eff.org
Indice
4.3.3
Messaggio
Links
Comando: LINKS
Parametri: [[<server remoto>] <schema_server>]
Col comando LINKS, un utente può ottenere l'elenco di tutti i
server conosciuti al server che risponde alla richiesta di
informazione. La lista di server 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 è 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 server con
un nome coerente con lo schema_server *.au;
:WiZ LINKS *.bu.edu *.edu ; messaggio LINKS da WiZ al primo server
il cui nome è coerente con lo schema *.edu per una lista di server
che soddisfano lo schema *.bu.edu.
Indice
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"
Indice
4.3.5
Messaggio
Connect
Comando: CONNECT
Parametri: <server_destinazione> [<porta> [<server
remoto>]]
Il comando CONNECT può essere usato per forzare un server a stabilire
una nuova ed immediata connessione ad un altro server. CONNECT è un comando
privilegiato ed è disponibile solamente agli operatori IRC. Dato
un server remoto, allora il tentativo di connessione viene
effettuato da quel server al <erver_destinazione> attraverso
la porta <porta>. [Ndr - 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]
Risposte numeriche:
ERR_NOSUCHSERVER (errore_server inesistente)
ERR_NOPRIVILEGES (errore_non hai i privilegi
dell'operatore)
ERR_NEEDMOREPARAMS (errore_necessitano più 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 server eff.org e csd.bu.edu sulla porta
6667.
Indice
4.3.6
Messaggio
Trace
Comando: TRACE
Parametri: [<server>]
Il comando TRACE è 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 così
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, finchè il
server il cui nome è contenuto nel parametro <server> non
viene raggiunto. Se viene
omesso il parametro <server>, è previsto che il comando
TRACE invii un messaggio al mittente, indicando con quali server
il server corrente ha una connessione diretta. Se
la destinazione data da <server> è un server effettivamente
collegato, allora al server di destinazione è è fatto obbligo
di notificare tutti i server e gli utenti connessi, anche se,
in effetti, solo agli operatori è permesso vedere gli utenti presenti.
Se la destinazione data da <server> è 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 è indirizzato ad
un altro server, tutti i server intermedi devono inviare una risposta
RPL_TRACELINK per indicare che il messaggio TRACE è passato attraverso
di loro e specificare quale sarà la destinazione immediatamente
successiva.
RPL_TRACELINK (risposta_traccia di collegamento)
Una risposta TRACE può 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 è coerente con lo schema *.oulu.fi
:WiZ TRACE AngelDust ;TRACE emesso da WiZ per il nick AngelDust
Indice
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 possibilità di inoltrare messaggi ADMIN ad altri
server.
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 è coerente con lo schema *.edu.
Indice
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 è stato attivato,
ed ogni altra informazione che può 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 è coerente con lo schema *.fi.
INFO Angel ; richiesta INFO dal server al quale Angel è connesso.
Indice
4.4
Invio
messaggi
Lo scopo principale del protocollo IRC è di fornire una base
comune per tutti i client 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.
Indice
4.4.1 Messaggi
Privati
Comando: PRIVMSG
Parametri: <destinatario>{,<destinatario>}
<testo da inviare>
PRIVMSG viene usato per inviare messaggi privati tra utenti. <destinatario>
è il nickname del destinatario del messaggio. <destinatario>
può anche essere una lista di nomi o canali, separata da virgole.
Il parametro <destinatario> può anche essere uno schema
di nome-macchina (#mask) oppure uno schema di nome-server ($mask).
In ambedue i casi il server invierà il
PRIVMSG a coloro che hanno un server oppure una macchina il cui
nome è coerente con lo schema fornito. Lo schema deve contenere
almeno un (1) punto "." e nessun carattere-jolly
dopo l'ultimo punto ".". Questo è 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 è 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 ìm receiving it !receiving it !'u>(768u+1n)
.br ; messaggio a Angel.
PRIVMSG
jto@tolsun.oulu.fi :Hello ! ; messaggio
ad un client su un server tolsun.oulu.fi con 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 è undergoing work,
expect interruptions ; messaggio a tutti gli utenti che hanno
una macchina il cui nome è coerente con *.edu.
Indice
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 è che una
risposta automatica non deve mai essere inviata come replica ad
un messaggio NOTICE. Questa regola si applica pure ai server -
essi non devono ritornare una risposta di errore al client, alla ricezione di un NOTICE. Questa
regola è 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 (client 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. [Ndr - Si tratta dei così detti bot - abbreviazione
della parola ceca "robot", programmi implementati sulla
macchina di un client che rimangono in
linea ed hanno un comportamento del tutto automatico]
Si veda PRIVMSG per maggiori
dettagli sulle risposte e gli Esempi.
Indice
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 visibilità di un utente è determinata come una combinazione
del mode dell'utente ed i comuni canali
sui quali si trovano sia l'utente inquisito che il richiedente.
Indice
4.5.1
Richiesta
Who
Comando: WHO
Parametri: [<nome> [<o>]]
Il messaggio WHO è usato da un client per generare una richiesta
la cui risposta è 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 può 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 può 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.
Indice
4.5.2
Richiesta
Whois
Comando: WHOIS
Parametri: [<server>] <schema-nick>[,<schema-nick>[,...]]
Questo messaggio è usato per chiedere informazioni su un particolare
utente. Il server risponderà a questo messaggio con diverse risposte
numeriche indicando i differenti statu 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 più recente invia la richiesta ad uno specifico server.
Questo perchè l'attuale periodo di inattività di un utente è conosciuto solo al server
al quale l'utente è direttamente connesso, mentre tutte le altre
informazioni sono note universalmente. (13)
Risposte numeriche:
ERR_NOSUCHSERVER (errore_server inesistente)
ERR_NONICKNAMEGIVEN (errore_non è 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 inattività)
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
Indice
4.5.3 Domanda Whowas
Comando: WHOWAS
Parametri: <nick> [<conto> [<server>]]
Whowas chiede informazioni su un nick che non esiste più 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
è controllato a ritroso e fornisce per prima la ricorrenza più
recente per il nick. Se viene trovata più di una presenza, vengono fornite più
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 è 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 più recenti per il nick Mermaid nell'archivio storico
per i nicks.
WHOWAS Trillian 1 *.edu ; ritorna l'informazione storica più recente
per "Trillian" dal primo server coerente con lo schema:
"*.edu".
Indice
4.6 Altri Messaggi
I messaggi di questa categoria non rientrano in nessuna di quelle
sopraelencate, ma sono parte integrante del protocollo.
Indice
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 server quando incontrano una presenza duplice nella
lista di nick validi, per rimuovere ambedue gli utenti. Questo
comando è disponibile anche agli operatori.
I client 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 può essere impiegato per fermare un uso scorretto
di grandi quantità di informazioni. Ogni utente può scegliere
di ricevere i messaggi KILL generati da altri per tenere d'occhio
i potenziali aree problematiche. In una
arena dove è necessario che i nick 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 KILL generati da server
,commento> è generalmente costruito con i dettagli relativi
all'origine dei nick in conflitto. Per quelli generati dagli utenti
è lasciato ad essi l'onere di fornire una ragione adeguata che soddisfi
chi vede il comando. Per prevenire/scoraggiare la creazione di
KILL truccati, per nascondere l'identità 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 più parametri)
ERR_NOSUCHNICK (errore_nick inesistente)
ERR_CANTKILLSERVER (errore_non può "uccidere" un
server)
Esempio:
KILL David (csd.bu.edu <- tolsun.oulu.fi)
; collisione di nickname tra csd.bu.edu e tolson.oulu.fi
Nota: è 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 server ad occuparsi del problema.
Indice
4.6.2
Messaggio
Ping
Comando: PING
Parametri: <server1> [<server2>]
Il messaggio PING è 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
attività 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 più in fretta possibile con un appropriato
messaggio PONG, per indicare che esso è presente e vivo. I server
non dovrebbero rispondere ai comandi PING ma contare sui PING
dall'altro capo della connessione per indicare che la connessione
è 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 è
ancora attivo.
PING WiZ ; messaggio PING inviato al nick WiZ
Indice
4.6.3
Messaggio
Pong
Comando: PONG
Parametri: <demone> [<demone2>]
Il messaggio PONG è una risposte al messaggio
ping. Se viene fornito il parametro <demone2>
questo messaggio deve essere inoltrato anche a quel demone. Il
parametro <demone> è 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
Indice
4.6.4
Messaggio
Error
Comando: ERROR
Parametri: <messaggio d'errore>
L'uso del comando ERROR è riservato ai
server per riportare ai propri operatori un errore grave oppure
fatale. Esso può 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 è 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 server 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 è 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 è implementato, deve essere generato un apposito
messaggio di errore oppure un errore generico di comando sconosciuto. Se il
messaggio è destinato ad un altro server deve essere
passato oltre (è richiesta una analisi elementare). Le risposte numeriche adatte
allo scopo sono elencate con i messaggi descritti qui di seguito.
Indice
5.1
Messaggio Away
Comando: AWAY
Parametri: [messaggio]
Con il messaggio AWAY i client 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 è quello sul quale il client è 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.
Indice
5.2
Messaggio Rehash
Comando: REHASH
Parametri: Nessuno
Il messaggio REHASH può 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.
Indice
5.3
Messaggio Restart
Comando: RESTART
Parametri: Nessuno
Il comando RESTART può essere usato esclusivamente da un operatore per forzare
un server ad attivare la procedura di riavvio. Questo messaggio
è 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 è 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.
Indice
5.4
Messaggio Summon
Comando: SUMMON
Parametri: <utente> [<server>]
Il comando SUMMON può essere usato per inviare, ad utenti che si trovano su
una macchina su cui è 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 è in linea;
c) il server che processa il comando può 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 è connesso che viene considerato come server destinazione.
Se SUMMON non è 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
è attivo il server "tolsun.oulu.fi".
Indice
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
Indice
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 è 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 server
come mittenti dei WALLOPS.
Risposte numeriche:
ERR_NEEDMOREPARAMS (Errore_necessitano più 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.
Indice
5.7
Messaggio Userhost
Comando: USERHOST
Parametri: <nick>{<carattere-spazio><nickname>}
Il comando USERHOST prende una lista contenente fino a 5 nick 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 più parametri)
RPL_USERHOST (risposta_USERHOST)
Esempi:
USERHOST Wiz Michael Marty p ; Richiesta
di informazioni USERHOST sui nick "Wiz", "Michael", "Marty"
e "p"
Indice
5.8
Messaggio ISON
Comando: ISON
Parametri: <nick>{<carattere-spazio><nick>}
Il comando ISON è stato implementato per fornire un mezzo veloce ed efficiente
per sapere se un dato nick è correntemente presente su IRC.
ISON prevede solo un (1) parametro: una lista di nick separati da spazi. Ogni nick della lista
che sia attualmente presente, viene aggiunto dal server
alla stringa contenente le risposte. Così la stringa di risposta può 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 nick dati nel parametro. L'unico limite sul numero di
nick che può essere controllato, è dato dalla lunghezza della riga che non deve
eccedere i 512 caratteri, altrimenti verrà troncata dal server. ISON è processato solamente
dal server locale del client che manda il comando e non viene
passato ad altri servers.
Risposte numeriche:
ERR_NEEDMOREPARAMS (Errore_necessitano più parametri)
RPL_ISON (risposta_utente
in linea)
Esempi:
ISON phone trillian WiZ jarlek Avalon Angel Monstah ; esempio di richiesta ISON per 7 nicks.
Indice
6. RISPOSTE
Quella che segue è una lista di risposte numeriche che sono generate
in risposta ai comandi descritti sopra. Ogni risposta
numerica è data con il suo numero, il nome e la relativa stringa esplicativa.
Indice
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 è
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 è 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 è un operatore di canale (o non è 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 è 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
è sconosciuto al server.
422 ERR_NOMOTD ":MOTD File is missing"
Il server non ha potuto aprire il proprio file MOTD. [Ndr - MOTD = Message Of
The Day (messaggio del giorno)]
423 ERR_NOADMININFO "<server> :No administrative
info available"
Risposta inviata da un server in risposta ad un messaggio ADMIN quando c'è 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 già correntemente in uso.
436 ERR_NICKCOLLISION "<nick> :Nickname collision KILL"
Risposta inviata da un server ad un client quando scopre una collisione di nickname
(registrazione di un nick che già 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 è sul canale dato.
442 ERR_NOTONCHANNEL "<channel> :Yoùre not on that channel"
Risposta inviata dal server ogni volta che un client tenta un comando riferito
ad un canale del quale non è membro.
443 ERR_USERONCHANNEL "<user> <channel> :is already on channel"
Risposta inviata quando un client cerca di invitare un utente nel canale nel
quale già 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 è 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 è 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 è richiesta una parola d'ordine e quest'ultima non
è stata fornita oppure è 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- Yoù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> :Yoù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 è 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 è 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 è stato inviato
con un parametro nickname e che la modalità mode inviata non è 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.
Indice
6.2 Risposte ai
comandi.
300 RPL_NONE Replica non usata.
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 è composta come
segue:
<reply> ::=
<nick>['*'] '=' <'+'|'-'><hostname>
L'asterisco '*' indica se un client è 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 è inviata
ad ogni client che invii un messaggio ad un client che abbia
settato il comando AWAY. RPL_AWAY è inviata solo dal server al quale
il client è 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 è in questo caso inserito come carattere e non come wild card.
Per ogni insieme di risposte, solamente RPL_WHOISCHANNELS può apparire più di
una volta (per liste lunghe di nomi di canali). Il caratteri
'@' e '+' affiancati al nome del canale indicano se un client è operatore di
quel canale o se gli è stato accordato il permesso di parlare su un canale moderato.
La replica RPL_ENDOFWHOIS è 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'è 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 è 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 è stato accettato
e quindi è 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> è la versione del software in uso (incluse tutte
le revisioni ed i livelli di aggiornamento) e il parametro <debuglevel>
è usato per indicare se il server lavora in "debug mode" [Ndr - Modo
diagnostico]. Il campo "comments" può 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 è inviata solamente se è 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_NAMREPLY "<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 dà
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 'ban' 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 è 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 'informazionì 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 è più 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 è 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 è 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'è 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 è 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 server 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 è 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: città, stato e paese in cui esso si trova, seguita
da informazioni sull'università e il dipartimento (RPL_ADMINLOC2) e, per ultimo,
il contatto amministrativo per il server (è richiesto un indirizzo e-mail) nella
risposta RPL_ADMINEMAIL. (15)
Indice
6.3 Risposte numeriche
riservate.
Queste risposte numeriche non state
descritte prima in quanto esse rientrano in una delle
seguenti categorie:
1.
non più 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
Indice
7. AUTENTICAZIONE
DI CLIENT E SERVER
I client e i server 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
è 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 più usuale, è 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 è cosa facile determinare con sicurezza chi
si trovi all'altro capo di una connessione, l'uso delle parole d'ordine è fortemente
consigliabile nelle connessioni tra server in aggiunta a misure di altra natura
quale l'uso di un ident server.
Indice
8. Implementazioni
attuali
L'unica implementazione corrente di
questo protocollo è IRC server versione 2.8. [Ndr - Naturalmente questa affermazione era valida al momento della pubblicazione
di questo documento nel maggio 1993: già al momento di questa traduzione (giugno
1997) non lo è più]. (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 compatibilità verso
versioni precedenti, l'implementazione di alcune parti
di questo documento non è 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.
Indice
8.1 Protocollo
Network: TCP - perchè esso trova qui un applicazione ottimale.
L'IRC è 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 è disponibile su vasta scala al momento.
Indice
8.1.1 Sostegno per
Unix sockets
Dato che il campo d'azione degli Unix
sockets permette operazioni ascolto/connessione, l'implementazione corrente
può 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.
Indice
8.2 Analisi dei comandi
Per fornire un valido I/O (Input/Output)
'non-buffered' in rete, sia per i client 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 più recenti. è
stata stabilita per il buffer un ampiezza di 512 byte in modo che possa contenere
un messaggio completo, anche se, normalmente, contiene più 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.
Indice
8.3 Invio del
messaggio
É 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 buffer interni, il server ha spesso enormi
quantità di dati da inviare (specialmente quando si forma un nuovo link server-server)
ed i piccoli buffer 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. [Ndr - Acronimo di First In, First Out, un modello di organizzazione di dati] Una tipica "send queue"
può arrivare fino a 200 Kbyte 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 analizzerà 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 più grandi.
Indice
8.4 Connessione 'Liveness'
Per controllare quando una connessione
si sia persa oppure non risponda più, 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, verrà 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 è senz'altro meglio chiudere una connessione
lenta piuttosto che il server si blocchi.
Indice
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 server 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 server con funzione
di DNS/authentication). Il server deve inviare queste informazioni con NICK
seguito da USER.
Indice
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
è molto facile che vengano commessi errori - il meno rilevante dei quali sono
le cosiddette "race conditions". [Ndr - Condizioni per la corretta
risoluzione delle quali la variabile tempo è di importanza
essenziale]
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.
Indice
8.6.1 Scambio di informazioni
di stato fra server al momento della connessione
L'ordine delle informazioni di stato
che vengono scambiate tra server è essenziale. L'ordine
richiesto è il seguente:
- tutti gli altri server conosciuti;
- tutte le informazioni conosciute sugli utenti;
- tutti le informazioni conosciute sui canali.
Le informazioni riguardanti
i server 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 topic dei canali *NON* vengono scambiati in questa circostanza:
il comando TOPIC cancella ed aggiorna ogni informazione topic precedente, cosicchè,
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 server che gia esistano hanno luogo prima che possano aver luogo le collisioni sui nick
dovute al fatto che un secondo server introduce un nick che gia esista su un
altro). Dal momento che la rete IRC è 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 server indica
allora il luogo dove la rete necessita di uno split.
Indice
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 è necessario generare
od usare altri messaggi.
Indice
8.8 Terminazione di
connessioni server-server
Se una connessione server-server viene chiusa, che sia per un messaggio remoto SQUIT sia
per cause 'naturalì, il resto della rete IRC connessa deve essere informata
della sconnessione dal server che ha scoperto la chiusura che invierà 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).
Indice
8.9 Seguire la traccia dei cambi di nickname
Tutti i server IRC devono tenere una
traccia storica dei cambi recenti di nick. Questo è richiesto per permettere
al server di avere una possibilità di restare in contatto con la situazione
quando cambi di nick si succedano a gran velocità (race
conditions) insieme con comandi che trattano i nick 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 è 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
possibilità di trovarsi in situazioni difficoltose a causa della velocità con
cui si succedono le operazioni (race conditions), ma difficoltà 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 è comunque limitata da fattori diversi (per esempio dalla disponibilità
di memoria, ecc.).
Indice
8.10 Controllo del
flood dei clients
Con una grande
rete IRC di server interconnessi, è molto facile per qualsiasi client connesso
alla rete, di produrre un flusso continuo di messaggi che finisce non solo per
floodare [Ndr - flood vale allagamento, alluvione, inondazione] 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 è stata scritta nel server ed applicata a tutti
i client 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 è 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 può mandare 1 messaggio
ogni 2 secondi senza subire penalità.
Indice
8.11 Letture
veloci per evitare blocchi
In un ambiente real-time, è essenziale che tutte le azioni dei
server attendano il minor tempo possibile per essere espletate,
cosicchè tutti i client 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 attività dovrebbe essere espletata
con pause di funzionamento brevi.
Indice
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 routine 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.
Indice
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 è stata quella di scrivere degli insiemi di routine capaci di cooperare
in maniera efficiente con il resto del software dei server usando funzioni di
I/O che non comportano pause di funzionamento.
Indice
8.12 File di
configurazione
Per fornire un modo flessibile per configurare e far funzionare
il programma server, è auspicabile l'impiego di un file di configurazione che
contenga istruzioni per il server sugli aspetti seguenti:
- da quali host accettare connessioni
da client;
- quali host autorizzare a connettersi
come servers;
- a quali host possa connettersi
(sia in modo attivo che passivo);
- informazioni sulla collocazione del server
(per esempio: università, città/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
client 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 è il minimo richiesto per un server che desideri fare una
connessione con un altro server. Altre voci che potrebbero essere utili sono:
- quali server altri server possono
introdurre;
- profondità permessa ad una ramificazione
del server;
- l'orario durante il quale i
client si possono connettere.
Indice
8.12.1 Permettere
ai client di connettersi
Il server dovrebbe usare qualcosa come una 'lista di controllo
di accessò (contenuta nel file di configurazione oppure
altrove) che venga letta all'accensione ed usata per decidere quali host possano
usare i client per connettersi. Sia la dichiarazione 'deny' (negato) che 'allow'
(permesso) dovrebbero essere implementate per fornire
la flessibilità necessaria per il controllo di accesso degli hosts.
Indice
8.12.2 Operatori
Concedere i privilegi di operatore ad
una persona che distruttiva, può 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 unadi esse sia di solito facilmente intuibile. Se si memorizzano le
parole d'ordine per gli operatori nei file di configurazione
è consigliabile codificarle ed immagazzinarle in un formato criptato (per esempio
usando il crypt(3) di Unix) per prevenire facili ruberie.
Indice
8.12.3 Permettere
ai server di connettersi
l'interconnessione di server non è una
cosa banale: una cattiva connessione può avere una grande influenza sull'efficienza
di IRC: cosi ogni server dovrebbe avere una lista di server ai quali possa collegarsi,
e di server 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 server che possono e non
possono connettersi, il file di configurazione dovrebbe anche contenere la parola
d ordine ed altre caratteristiche di quel link.
Indice
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.
Indice
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'è limite imposto ad utenti
non locali, cosi che il server rimane (ragionevolmente) coerente con tutti gli
altri per quanto riguarda l'associazione ai canali.
Indice
9. PROBLEMI CORRENTI
Vi sono un certo numero di problemi già 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.
Indice
9.1
Adattamento a situazioni
di dimensioni rilevanti.
É riconosciuto ampiamente che questo protocollo
non si adatta sufficientemente bene quando opera su larga scala. Il maggior problema
viene dalla necessità che tutti i server sappiano di tutti gli altri server
ed utenti e che le informazioni che li riguardano siano aggiornate non appena
subiscono cambiamenti. É inoltre desiderabile tenere basso il numero dei servers,
così che la lunghezza del percorso tra due punti sia la più breve [Ndr - Evidentemente
in termini di numero di nodi intermedi] e che l'albero della rete
il più ramificato possibile.
Indice
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 validità specifico e non sono permessi duplicati all'interno
di quell'ambito. Attualmente è possibile per gli utenti
scegliere un'etichetta in ognuno dei tre ambiti, con la possibilità di creare
collisioni.
è chiaro a molti che questo problema pone la necessità 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.
Indice
9.2.1 Nicks
L'idea dei nick su IRC è molto conveniente da usare per gli utenti
che parlano gli uni con gli altri fuori da un canale,
ma c'è solamente uno spazio finito per i nick come ci si poteva tranquillamente
aspettare, non è inconsueto che più persone vogliano usare lo stesso nick. Se
un medesimo nickname viene scelto da due persone che
usano questo protocollo, o una delle due non riuscirà nel suo intento, oppure
tutte e due saranno rimosse con l'uso di KILL (4.6.1).
Indice
9.2.2 Canali
l'attuale organizzazione dei canali richiede
che tutti i server siano a conoscenza di tutti i canali, dei loro membri e delle
loro proprietà. 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.
Indice
9.2.3 Servers
Sebbene il numero dei server 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).
Indice
9.3 Algoritmi
In qualche circostanza, nel software per il server, non è 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 bug oppure introduce contraddizioni nella
rete esistente.
A causa della mancanza di garanzia dell'unicità per le etichette interne e globali, si danno molto spesso dei problemi di coordinamento
temporale (race condition). Queste condizioni hanno generalmente origine dalfattoche
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.
Indice
10. SUPPORTO
E DISPONIBILITÁ
Mailing list 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
Indice
11. CONSIDERAZIONI
SULLA SICUREZZA
La sicurezza è discussa nelle sezioni 4.1, 4.1.1, 4.1.3, 5.5, e
7.
Indice
12. INDIRIZZI
DEGLI AUTORI
NOTE
(1) - Ci si riferisce a 4 anni trascorsi all'epoca
del rilascio della RFC originale: l'età al momento attuale
(1977) di IRC supera gli 8 anni.
Indice
(2) - Questo documento non descrive esattamente il
protocollo IRC attualmente utilizzato (1977), ma non risultano esistere
documenti successivi e più aggiornati così ampi e comprensivi.
Indice
(3) - Sembra che le attuali versioni dei server non
permettano comunque l'accesso a più di 10 canali, ma esistono diverse
versioni sulla stessa rete che si comportano in modo diverso.
Indice
(4) - "Socket", come "file", non
si traduce in italiano, di solito. In parole molto povere, un socket è un "file
di rete" cioè corrisponde ad un canale e non a
dei dati su una memoria di massa, ma può essere letto e scritto come un file.
Indice
(5) - Alle tre precedenti dovrebbe essere aggiunta
la seguente condizione: 4. se il canale è +l il numero
massimo di utenti sul canale non deve essere raggiunto (o superato).
Indice
(6) - Dovrebbe (anzi di solito lo è ) essere data anche
la RPL_NAMEREPLY.
Indice
(7) - Non sembra facile poter pensare ad una trasformazione
di IRC senza nicknames.
Indice
(8) - Questi modi ormai non riflettono più quelli attualmente
disponibili nelle attuali versioni usate su IRCNet.
Indice
(9) - Anche questi modi non corrispondono esattamente
a quelli attualmente in uso su IRCNet: tanto per fare un esempio,
non esiste più il modo "s" ed esiste il famigerato modo "r".
Indice
(10) - L'estensione del comando non dovrebbe più essere
possibile con le nuove versioni del server IRCNet.
Indice
(11) - I server attuali rispondono ad un numero abbastanza
maggiore di richieste, ad esempio: "/stats z", "/stats d",
"/stats t".
Indice
(12) - Attualmente anche
un operatore può vedere gli utenti connessi solo al suo server. Nelle precedenti
versioni, gli operatori potevano effettivamente vedere gli utenti anche su altri
servers.
Indice
(13) - Il /whois si comporta in maniera leggermente
differente in realtà vengono visualizzate tutte le
informazioni solo se il nick richiesto è sullo stesso server di chi esegue il
comando, altrimenti vengono visualizzate solo le informazioni generali (nick,
hostname e servername).
Indice
(14) - Il commando SUMMON è ormai disabilitato quasi
su ogni server.
Indice
(15) - Per ottenere un elenco completo delle risposte
numeriche e del loro significato è opportuno fare riferimento direttamente ai sorgenti della versione del programma server alla quale
si è interessati. - Se la memoria non mi abbandona,
si trovano nel file "numerics.h".
Indice
(16) - La versione attuale è la 2.9 e la 2.9.2p2 quella
maggiormente usata.(Giugno '97)
Articolo a cura di :
Roberto "Rob" Timmoneri rob@ircitaly.net
(Traduzione dell'RFC 1459 in lingua originale)
Ultima revisione: 25 Febbraio 2004
|
RFC 1459
