Untitled Document
mIRC in Italiano - Script - Forum - Imposta come Home Page - Aggiungi ai Preferiti - Home - Chat
Utenti connessi: - Visitatori oggi: - Visitatori totali: - Pagine viste oggi:


NewsLetter


localirc
-
----
-
----
-
----
-
----
-
  - Introduzione
- Generalità su IRC
- Le basi di IRC: Canali, Modi, ecc. ecc.
- Clients.
- F.A.Q.s
----
-
  - Introduzione e concetti
- Info sui messaggi
- Messaggi facoltativi
----
-
----
-
----
-
----
-
----
-
----
-
----
-
----
-
----
-
----
-
----
-
----
-
----
-
----
-
----
-
----
-
----
-
----
-
----
-
----
-
----
-
----
-
----

-
----
-
-
-
-
-
----
-
----
-
----
-
----
-
----
-
----
-
----
-
----
-
----
-
----
-
----
-
----
-
----
-
----
-
----
-
----
-
----
-
----
-
----
-
----
-
----
-
----
-
----
-
----
-
----
-
----
-
----
-
----
-
----
-
----
-
----
-
----
-
----
-
----
-
----
-
----
-
----

----
RFC 1459 in Italiano

A.1. RFC1459 - Il protocollo IRC

Torna alla sezione precedente

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.

Torna all'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
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:

  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

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.

Passa alla sezione successiva

Torna all'indice



  Ultime dal forum IRC
  Ultimi File Inseriti
Diablo III (14141)
Fancazzista Scr... (18206)
Sensuality scri... (7517)
Grand Theft Aut... (5069)
Stealth Script ... (8228)
-SagittarioScri... (18079)
Paradise Script (13518)
Trivia Game 200... (11705)
Ircap Script 8.... (5101)
RawScript 2.0 (8350)


 

 


Cerca nel sito

Le ultime news:



Sondaggio
Cosa vorresti di nuovo?

Risultati | Archivi

Statistiche Download
Database:
283 Files
241 Mb
Scaricati:
2637389 Files
Totale: 5568307Mb

Upload
Hai realizzato uno Script? Una addon? Una tcl? Un articolo? Qualsiasi cosa? Mandacelo ora! Utilizza il form upload per inviarci il tuo materiale e se lo riteniamo idoneo lo vedrai pubblicato nel portale!
[ Upload ]

Chat
Inserisci il tuo nick:



| Contattaci | Pubblicità | Staff |
Il presente materiale è Copyright TuttoIRC.it 2005. Leggi il Disclaimer