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.
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:
- messaggio Pass
- messaggio Nick
- messaggio User
Torna all'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). è 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
Torna all'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.
Torna all'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. è 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 il parametro 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.
Torna all'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.
Torna all'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.
Torna all'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.
Torna all'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).
Torna all'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.
Torna all'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:
- Il client deve essere invitato se il canale
è ad invito (mode +i);
- Il nick/nome_utente/nome_macchina del client
non devono corrispondere a ban attivi;
- 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
Torna all'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".
Torna all'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.
Torna all'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.)
Torna all'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.
Torna all'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.
Torna all'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.
Torna all'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
Torna all'indice
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
Torna all'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)
Torna all'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.
Torna all'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".
Torna all'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
Torna all'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.
Torna all'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"
Torna all'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.
Torna all'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
Torna all'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.
Torna all'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.
Torna all'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.
Torna all'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.
Torna all'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.
Torna all'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.
Torna all'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.
Torna all'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
Torna all'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".
Torna all'indice
4.6 Altri Messaggi
I messaggi di questa categoria non rientrano in
nessuna di quelle sopraelencate, ma sono parte integrante
del protocollo.
Torna all'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.
Torna all'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
Torna all'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
Torna all'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.
Torna all'indice