5.1 Messaggio Away
Comando: AWAY
Parametri: [messaggio]
Con il messaggio AWAY i client possono predisporre
una riga di risposta automatica per ogni comando
PRIVMSG loro indirizzato (non ad un canale sul quale
essi si trovano).
La risposta automatica viene inviata dal server
al client mittente del comando PRIVMSG. L'unico
server a rispondere è quello sul quale il client
è localmente connesso.
Il messaggio AWAY usato sia con un parametro (per
predisporre un messaggio AWAY) che senza parametri
(per annullare il messaggio AWAY).
Risposte numeriche:
RPL_UNAWAY (risposta_utente
non in AWAY)
RPL_NOWAWAY (risposta_utente in AWAY)
Esempi:
AWAY :Gone to lunch. Back in 5 ;
predispone il messaggio away in "Gone to lunch.
Back in 5' (Andato a pranzo, Di ritorno in 5 minuti).
:WiZ AWAY ; disattiva il messaggio away di WiZ.
Torna all'indice
5.2 Messaggio Rehash
Comando: REHASH
Parametri: Nessuno
Il messaggio REHASH può essere usato dall'operatore
per forzare il server a rileggere e riprocessare
il suo file di configurazione.
Risposte numeriche:
RPL_REHASHING (risposta_rehashing
in corso)
ERR_NOPRIVILEGES (errore_non hai i privilegi
dell'operatore)
Esempi:
REHASH ; messaggio da un client,
con status operatore, ad un server per chiedergli
di rileggere il suo file di configurazione.
Torna all'indice
5.3 Messaggio Restart
Comando: RESTART
Parametri: Nessuno
Il comando RESTART può essere usato esclusivamente
da un operatore per forzare un server ad attivare
la procedura di riavvio. Questo messaggio è facoltativo
in quanto potrebbe essere visto come un rischio
permettere a persone non meglio qualificate di connettersi
al server come operatori ed eseguire questo comando,
causando (come minimo) un; interruzione del servizio.
Il comando RESTART deve sempre essere processato
completamente dal server al quale il client mittente
è connesso, e non deve essere inoltrato ad altri
server.
Risposte numeriche:
ERR_NOPRIVILEGES (errore_non
hai i privilegi dell'operatore)
Esempi:
RESTART ; non sono richiesti parametri.
Torna all'indice
5.4 Messaggio Summon
Comando: SUMMON
Parametri: <utente> [<server>]
Il comando SUMMON può essere usato per inviare,
ad utenti che si trovano su una macchina su cui
è attivo un server IRC, un messaggio per chiedere
loro di unirsi a IRC. Questo messaggio mandato solamente
se il server destinazione del messaggio:
a) ha il comando SUMMON abilitato;
b) l'utente è in linea;
c) il server che processa il comando può inviare
dell'output all'utente.
Se non viene dato alcun parametro <server>,
il server cerca di SUMMON (convocare) l'<utente>
sul server sul quale il client è connesso che viene
considerato come server destinazione.
Se SUMMON non è attivo su un server, esso deve mandare
la risposta numerica ERR_SUMMONDISABLED e passare
oltre il messaggio.
(14)
Risposte numeriche:
ERR_NORECIPIENT (errore_nessun
destinatario)
ERR_FILEERROR (errore_errore
sul file)
ERR_NOLOGIN (errore_non
in linea)
ERR_NOSUCHSERVER (errore-server inesistente)
RPL_SUMMONING (risposta_convocazione
in corso)
Esempi:
SUMMON jto ; convoca l'utente jto
sulla macchina del server
SUMMON jto tolsun.oulu.fi ; convoca l'utente jto
sulla macchina sulla quale è attivo il server
"tolsun.oulu.fi".
Torna all'indice
5.5 Comando Users, Utenti
Comando: USERS
Parametri: [<server>]
Il comando USERS invia in risposta una lista di
utenti collegati ad un server in un formato simile
a quello di who(1), rusers(1) e finger(1). Alcuni
disabilitano questo comando dal loro server per
ragioni di sicurezza. Se disabilitato, la relativa
risposta numerica, indicante la disabilitazione,
deve essere fornita.
Risposte numeriche:
ERR_NOSUCHSERVER (errore_server
inesistente)
ERR_FILEERROR (errore_errore
sul file)
ERR_USERSDISABLED (errore_comando USERS disabilitato)
RPL_USERSSTART (risposta_USERS:
inizio)
RPL_USERS (risposta_USERS)
RPL_NOUSERS (risposta_nessun
utente)
RPL_ENDOFUSERS (risposta_fine
degli utenti)
Risposta se disabilitato:
ERR_USERSDISABLED (errore_comando
USERS disabilitato)
Esempi:
USERS eff.org ; richiede una lista
di utenti connessi su eff.org
:John UTENTI tolsun.oulu.fi ; richiesta di John
per una lista di utenti connessi sul server tolsun.oulu.fi
Torna all'indice
5.6 Comando Operwall
Comando: WALLOPS
Parametri: Testo da mandare a tutti gli operatori
in linea
Manda un messaggio a tutti gli operatori in linea.
Dopo aver implementato il WALLOPS come un comando
a disposizione del generico utente, ci si è accorti
che di esso veniva spesso e volentieri fatto un
uso improprio per mandare messaggi ad un sacco di
gente (in maniera molto simile al WALL).
Per questo motivo sarebbe bene che la corrente implementazione
del comando WALLOPS sia considerata come un esempio
e che siano in futuro riconosciuti solo i server
come mittenti dei WALLOPS.
Risposte numeriche:
ERR_NEEDMOREPARAMS (Errore_necessitano
più parametri)
Esempi:
:csd.bu.edu WALLOPS :Connect '*.uiuc.edu
6667' from Joshua ; messaggio WALLOPS da csd.bu.edu
che annuncia un messaggio CONNECT ricevuto da
Joshua e messo in atto.
Torna all'indice
5.7 Messaggio Userhost
Comando: USERHOST
Parametri: <nick>{<carattere-spazio><nickname>}
Il comando USERHOST prende una lista contenente
fino a 5 nick separati da un carattere spazio, e
invia una lista di informazioni su ogni nick che
ha trovato. La lista ha le risposte separate da
uno spazio.
Risposte numeriche:
ERR_NEEDMOREPARAMS (Errore_necessitano
più parametri)
RPL_USERHOST (risposta_USERHOST)
Esempi:
USERHOST Wiz Michael Marty p ; Richiesta
di informazioni USERHOST sui nick "Wiz", "Michael",
"Marty" e "p"
Torna all'indice
5.8 Messaggio ISON
Comando: ISON
Parametri: <nick>{<carattere-spazio><nick>}
Il comando ISON è stato implementato per fornire
un mezzo veloce ed efficiente per sapere se un dato
nick è correntemente presente su IRC.
ISON prevede solo un (1) parametro: una lista di
nick separati da spazi. Ogni nick della lista che
sia attualmente presente, viene aggiunto dal server
alla stringa contenente le risposte. Così la stringa
di risposta può essere vuota (nessuno dei nick presente),
oppure viene inviata una copia esatta della stringa
dei parametro (tutti i nick presenti) o qualsiasi
altra sottoinsieme dei nick dati nel parametro.
L'unico limite sul numero di nick che può essere
controllato, è dato dalla lunghezza della riga che
non deve eccedere i 512 caratteri, altrimenti verrà
troncata dal server. ISON è processato solamente
dal server locale del client che manda il comando
e non viene passato ad altri servers.
Risposte numeriche:
ERR_NEEDMOREPARAMS (Errore_necessitano
più parametri)
RPL_ISON (risposta_utente
in linea)
Esempi:
ISON phone trillian WiZ jarlek Avalon
Angel Monstah ; esempio di richiesta ISON per
7 nicks.
Torna all'indice
6. RISPOSTE
Quella che segue è una lista di risposte numeriche
che sono generate in risposta ai comandi descritti
sopra. Ogni risposta numerica è data con il suo
numero, il nome e la relativa stringa esplicativa.
Torna all'indice
6.1 Risposte d'Errore
401 ERR_NOSUCHNICK "<nickname> :No such
nick/channel"
Risposta inviata per indicare che il parametro nickname
dato ad un comando è attualmente non in uso.
402 ERR_NOSUCHSERVER "<server name> :No
such server"
Risposta inviata per indicare che il nome del server
dato attualmente non esiste.
403 ERR_NOSUCHCHANNEL "<channel name> :No
such channel"
Risposta inviata per indicare che il nome del canale
fornito non è valido.
404 ERR_CANNOTSENDTOCHAN "<channel name>
:Cannot send to channel"
Risposta inviata ad un utente il quale: a) non si
trova su un canale con mode +n, oppure b) non è
un operatore di canale (o non è in mode utente +v)
su un canale in mode +m e sta cercando di inviare
un PRIVMSG a quel canale.
405 ERR_TOOMANYCHANNELS "<channel name>
:You have joined too many channels"
Risposta inviata agli utenti quando si sono aggregati
al numero massimo permesso di canali, e stanno cercando
di aggregarsi ad un altro canale.
406 ERR_WASNOSUCHNICK "<nickname> :There
was no such nickname"
Mandata in risposta ad un WHOWAS per indicare che
non ci sono informazioni nell'archivio storico per
quel nick.
407 ERR_TOOMANYTARGETS "<target> :Duplicate
recipients. No message\delivered"
Replica inviata in risposta ad un client che sta
cercando di mandare un PRIVMSG/NOTICE usando il
formato di destinazione user@host e per un user@host
che ha diverse presenze al momento attuale.
409 ERR_NOORIGIN ":No origin specified"
Messaggio PING o PONG al quale manca il parametro
che indica il mittente, necessario dal momento che
questi comandi devono funzionare senza prefissi
validi.
411 ERR_NORECIPIENT ":No recipient given (<Command>)"
412 ERR_NOTEXTTOSEND ":No text to send"
413 ERR_NOTOPLEVEL "<mask> :No toplevel domain
specified"
414 ERR_WILDTOPLEVEL "<mask> :Wildcard in
toplevel domain"
412 / 414 sono date da PRIVMSG per indicare che
il messaggio non è stato inoltrato per qualche ragione.
ERR_NOTOPLEVEL e ERR_WILDTOPLEVEL sono errori che
vengono inviati come risposta quando si tenta un
uso non valido di "PRIVMSG $<server>" o "PRIVMSG
#<host>".
421 ERR_UNKNOWNCOMMAND "<Command> :Unknown
Command"
Risposta inviata ad un client registrato per indicare
che il comando proposto è sconosciuto al server.
422 ERR_NOMOTD ":MOTD File is missing"
Il server non ha potuto aprire il proprio file MOTD.
[Ndr - MOTD = Message Of The Day (messaggio del
giorno)]
423 ERR_NOADMININFO "<server> :No administrative
info available"
Risposta inviata da un server in risposta ad un
messaggio ADMIN quando c'è un errore nel reperimento
delle informazioni.
424 ERR_FILEERROR ":File error doing <file
op> on <file>"
Messaggio di errore generico, usato per informare
il fallimento di un operazione di trattamento di
file(s) durante il trattamento del messaggio.
431 ERR_NONICKNAMEGIVEN ":No nickname given"
Risposta inviata quando un parametro nickname richiesto
per l'esecuzione di un comando non viene trovato
432 ERR_ERRONEUSNICKNAME "<nick> :Erroneus
nickname"
Risposta inviata dopo aver ricevuto un messaggio
NICK il quale contiene caratteri non compresi nel
set definito per i nicks. Si veda la
sezione 4.1.2
per dettagli sui nickname validi.
433 ERR_NICKNAMEINUSE "<nick> :Nickname
is already in use"
Risposta inviata quando un messaggio NICK ha come
risultato un tentativo di cambiare il nickname con
un nickname già correntemente in uso.
436 ERR_NICKCOLLISION "<nick> :Nickname
collision KILL"
Risposta inviata da un server ad un client quando
scopre una collisione di nickname (registrazione
di un nick che già esiste da parte di un altro server).
441 ERR_USERNOTINCHANNEL "<nick> <channel>
:They aren't on that channel"
Risposta inviata dal server per indicare che l'utente
destinatario del comando non è sul canale dato.
442 ERR_NOTONCHANNEL "<channel> :Yoùre
not on that channel"
Risposta inviata dal server ogni volta che un client
tenta un comando riferito ad un canale del quale
non è membro.
443 ERR_USERONCHANNEL "<user> <channel>
:is already on channel"
Risposta inviata quando un client cerca di invitare
un utente nel canale nel quale già si trovano ambedue.
444 ERR_NOLOGIN "<user> :User not logged
in"
Risposta inviata dopo che il comando SUMMON per
un utente non stato portato a termine in quanto
l'utente non era in linea.
445 ERR_SUMMONDISABLED ":SUMMON has been disabled"
Risposta inviata come risposta al comando SUMMON.
Deve essere inviata da ogni server sul quale questo
comando non è implementato.
446 ERR_USERSDISABLED ":USERS has been disabled"
Risposta inviata in risposta al comando USERS. Deve
essere inviata da ogni server sul quale questo comando
non è implementato.
451 ERR_NOTREGISTERED ":You have not registered"
Risposta inviata dal server per indicare che il
client deve essere registrato prima che il server
permetta ad esso di essere analizzato nei dettagli.
461 ERR_NEEDMOREPARAMS "<Command> :Not
enough parameters"
Risposta inviata dal server in risposta a numerosi
comandi per indicare che il client non ha fornito
un numero di parametri sufficiente.
462 ERR_ALREADYREGISTRED ":You may not reregister"
Risposta inviata dal server per ogni connessione
che cerchi di cambiare parte delle notizie registrate
(quali password o informazioni concernenti l'utente)
mediante un secondo comando USER.
463 ERR_NOPERMFORHOST ":Your host isn't among
the privileged"
Risposta inviata ad un client che cerca di registrarsi
su un server che non permette connessioni dalla
macchina che tenta la connessione.
464 ERR_PASSWDMISMATCH ":Password incorrect"
Risposta inviata per indicare il fallimento di un
tentativo di registrare una connessione per la quale
è richiesta una parola d'ordine e quest'ultima non
è stata fornita oppure è stata indicata in forma
non corretta.
465 ERR_YOUREBANNEDCREEP ":You are banned from
this server"
Risposta inviata dopo un tentativo di connessione
e registrazione su un server predisposto per negarci
esplicitamente la connessione.
467 ERR_KEYSET "<channel> :Channel key
already set"
471 ERR_CHANNELISFULL "<channel> :Cannot
join channel(+l)"
472 ERR_UNKNOWNMODE "<char> :is unknown
mode char to me"
473 ERR_INVITEONLYCHAN "<channel> :Cannot
join channel (+i)"
474 ERR_BANNEDFROMCHAN "<channel> :Cannot
join channel (+b)"
475 ERR_BADCHANNELKEY "<channel> :Cannot
join channel (+k)"
481 ERR_NOPRIVILEGES ":Permission Denied- Yoùre
not an IRC operator"
Ogni comando che richiede i privilegi di operatore
per essere eseguito, deve inviare questa risposta
d'errore per indicare che il tentativo di eseguire
il comando non ha avuto successo.
482 ERR_CHANOPRIVSNEEDED "<channel> :Yoùre
not channel operator"
Ogni comando che richiede i privilegi di operatore
di canale per essere eseguito (quale, ad esempio,
il messaggio MODE) deve mandare questo errore se
il client sta facendo un tentativo di eseguire il
comando e non è un operatore sul canale specificato.
483 ERR_CANTKILLSERVER ":You cant kill a server!"
Ogni tentativo di usare il comando KILL su un server
deve essere rifiutato e questo messaggio d'errore
deve essere inviato direttamente al client.
491 ERR_NOOPERHOST ":No O-lines for your host"
Se un client invia un messaggio OPER ed il server
non è stato configurato per permettere connessioni
dalla macchina del client come operatore, deve essere
inviata questa risposta d'errore.
501 ERR_UMODEUNKNOWNFLAG ":Unknown MODE flag"
Risposta inviata dal server per indicare che un
messaggio MODE è stato inviato con un parametro
nickname e che la modalità mode inviata non è stata
riconosciuta.
502 ERR_USERSDONTMATCH ":Can't change mode for
other users"
Errore Inviato a qualsiasi utente che cerchi di
prender visione o cambiare gli user mode per un
utente che non sia se stesso.
Torna all'indice
6.2 Risposte ai comandi.
300 RPL_NONE Replica non usata.
302 RPL_USERHOST ":[<reply>{<space><reply>}]"
Formato di replica usato da USERHOST per elencare
risposte alla lista che compare nella richiesta.
La stringa di replica è composta come segue:
<reply> ::= <nick>['*']
'=' <'+'|'-'><hostname>
L'asterisco '*' indica se un client è registrato
come operatore. I caratteri '-' o '+' indicano rispettivamente
se il client ha predisposto oppure no un messaggio
di AWAY.
303 RPL_ISON ":[<nick> {<space><nick>}]"
Formato di replica usato da ISON per elencare risposte
alla lista che compare nella richiesta.
301 RPL_AWAY "<nick> :<away message>"
305 RPL_UNAWAY ":You are no longer marked as
being away"
306 RPL_NOWAWAY ":You have been marked as being
away"
Queste repliche sono usate con il comando AWAY (se
permesso). RPL_AWAY è inviata ad ogni client che
invii un messaggio ad un client che abbia settato
il comando AWAY. RPL_AWAY è inviata solo dal server
al quale il client è connesso. Le repliche RPL_UNAWAY
e RPL_NOWAWAY sono inviate quando il client annulla
o predispone il messaggio AWAY.
311 RPL_WHOISUSER "<nick> <user>
<host> * :<real name>"
312 RPL_WHOISSERVER "<nick> <server>
:<server info>"
313 RPL_WHOISOPERATOR "<nick> :is an IRC
operator"
317 RPL_WHOISIDLE "<nick> <integer>
:seconds idle
318 RPL_ENDOFWHOIS "<nick> :End of /WHOIS
list"
319 RPL_WHOISCHANNELS "<nick> :{[@|+]<channel><space>}"
Le repliche dalla 311 alla 313 e dalla 317 alla
319 sono tutte generate in risposta ad un messaggio
WHOIS. Ammesso che sia presente un numero di parametri
sufficiente, il server che risponde deve formulare
o una risposta numerica tra quelle sopra elencate
(nel caso che il nick richiesto venga trovato),
oppure deve inviare una risposta di errore. L'asterisco
'*' in RPL_WHOISUSER è in questo caso inserito come
carattere e non come wild card. Per ogni insieme
di risposte, solamente RPL_WHOISCHANNELS può apparire
più di una volta (per liste lunghe di nomi di canali).
Il caratteri '@' e '+' affiancati al nome del canale
indicano se un client è operatore di quel canale
o se gli è stato accordato il permesso di parlare
su un canale moderato. La replica RPL_ENDOFWHOIS
è usata per segnalare la fine del trattamento del
messaggio WHOIS.
314 RPL_WHOWASUSER "<nick> <user>
<host> * :<real name>"
369 RPL_ENDOFWHOWAS "<nick> :End of WHOWAS"
Quando risponde ad un messaggio WHOWAS, il server
deve usare le repliche RPL_WHOWASUSER, RPL_WHOISSERVER
o ERR_WASNOSUCHNICK per ogni nickname della lista
presentata. Alla fine di ogni gruppo di risposte,
deve comparire un RPL_ENDOFWHOWAS (anche se c'è
stata una sola risposta e questa era un errore).
321 RPL_LISTSTART "Channel :Users Name"
322 RPL_LIST "<channel> <# visible>
:<topic>"
323 RPL_LISTEND ":End of /LIST"
Le repliche RPL_LISTSTART, RPL_LIST, RPL_LISTEND
segnano rispettivamente l'inizio, le vere e proprie
risposte con dati, e la fine delle repliche del
server al comando LIST. Se non ci sono canali disponibili
sui quali ritornare notizie, devono essere inviate
solo le repliche di inizio e fine.
324 RPL_CHANNELMODEIS "<channel> <mode>
<mode params>"
331 RPL_NOTOPIC "<channel> :No topic is
set"
332 RPL_TOPIC "<channel> :<topic>"
Quando si manda un messaggio TOPIC per definire
il topic del canale, viene inviata una delle due
repliche. SE il topic è definito viene Inviata la
replica RPL_TOPIC, diversamente viene Inviata la
replica RPL_NOTOPIC.
341 RPL_INVITING "<channel> <nick>"
Risposta inviata dal server per indicare che il
tentativo INVITE è stato accettato e quindi è stato
segnalato al client.
342 RPL_SUMMONING "<user> :Summoning user
to IRC"
Risposta inviata da un server in risposta ad un
messaggio SUMMON per indicare che sta convocando
quell'utente.
351 RPL_VERSION "<version>.<debuglevel>
<server> :<comments>"
Risposta inviata dal server per fornire informazioni
di tipo VERSION.
Il parametro <version> è la versione del software
in uso (incluse tutte le revisioni ed i livelli
di aggiornamento) e il parametro <debuglevel>
è usato per indicare se il server lavora in "debug
mode" [Ndr - Modo diagnostico]. Il campo "comments"
può contenere commenti sulla versione oppure ulteriori
notizie sulla versione.
352 RPL_WHOREPLY "<channel> <user>
<host> <server> <nick>\<H|G>[*][@|+]
:<hopcount> <real name>"
315 RPL_ENDOFWHO "<name> :End of /WHO list"
La coppia di repliche RPL_WHOREPLY e RPL_ENDOFWHO
sono usate per rispondere ad un messaggio WHO. La
replica RPL_WHOREPLY è inviata solamente se è stato
rintracciato un riscontro appropriato alla domanda
WHO. Se viene data una lista di parametri a supporto
del messaggio WHO message, deve essere inviata una
replica RPL_ENDOFWHO dopo aver processato ogni voce
della lista, intendendo per voce il parametro <name>.
353 RPL_NAMREPLY "<channel> :[[@|+]<nick>
[[@|+]<nick>[...]]]"
366 RPL_ENDOFNAMES "<channel> :End of /NAMES
list"
Per rispondere ad un messaggio NAMES, viene inviata
una coppia di repliche composta da RPL_NAMREPLY
e RPL_ENDOFNAMES dal server al client. Se non viene
trovato alcun canale, tra quelli dati con la domanda,
allora viene inviata solamente la replica RPL_ENDOFNAMES.
L'eccezione si dà quando il messaggio NAMES viene
inviato senza parametri e tutti i canali visibile
ed i loro contenuti, sono inviati in una serie di
repliche RPL_NAMEREPLY con RPL_ENDOFNAMES a segnarne
la fine.
364 RPL_LINKS "<mask> <server> :<hopcount>
<serverinfo>"
365 RPL_ENDOFLINKS "<mask> :End of /LINKS
list"
In risposta al messaggio LINKS, un server deve inviare
delle repliche usando la risposta numerica RPL_LINKS,
segnando la fine della lista usando la replica RPL_ENDOFLINKS.
367 RPL_BANLIST "<channel> <banid>"
368 RPL_ENDOFBANLIST "<channel> :End of
channel ban list"
Quando elenca i 'ban' attivi per un dato canale,
al server si richiede di inviare una lista usando
le repliche RPL_BANLIST e RPL_ENDOFBANLIST. Un messaggio
separato RPL_BANLIST è inviato per ogni ban attivo.
Dopo che i ban sono stati elencati (oppure se non
ne era prendente nessuno) deve essere inviata la
replica RPL_ENDOFBANLIST.
371 RPL_INFO ":<string>"
374 RPL_ENDOFINFO ":End of /INFO list"
Un server che risponde ad un messaggio INFO deve
essere in grado di mandare tutte le sue 'informazionì
in una serie di repliche RPL_INFO con la replica
RPL_ENDOFINFO ad indicare la fine della serie di
risposte.
375 RPL_MOTDSTART ":- <server> Message
of the day - "
372 RPL_MOTD ":- <text>"
376 RPL_ENDOFMOTD ":End of /MOTD Comando"
Quando viene trovato il file MOTD in risposta al
messaggio MOTD, il file viene mostrato riga per
riga, ognuna delle quali non è più lunga di 80 caratteri,
usando il formato di replica RPL_MOTD. Questa replica
(RPL_MOTD) dovrebbe essere preceduta da RPL_MOTDSTART
e seguita da RPL_ENDOFMOTD.
381 RPL_YOUREOPER ":You are now an IRC operator"
La replica RPL_YOUREOFOR è inviata ad un client
che ha espletato con successo un messaggio OPER
e guadagnato lo status operatore.
382 RPL_REHASHING "<config file> :Rehashing"
Se viene usata l'opzione REHASH ed un operatore
invia un messaggio REHASH, a quell'operatore viene
inviata la replica RPL_REHASHING.
391 RPL_TIME "<server> :<string showing
server's local time>"
Quando un server risponde ad un messaggio TIME,
deve inviare la risposta usando il format RPL_TIME
descritto sopra. La stringa che mostra l'orario
deve contenere solamente il giorno e l'orario corretti.
Non sono necessari altri requisiti.
392 RPL_USERSSTART ":UserID Terminal Host"
393 RPL_USERS ":%-8s %-9s %-8s"
394 RPL_ENDOFUSERS ":End of users"
395 RPL_NOUSERS ":Nobody logged in"
Quando il messaggio USER è trattato da un server,
sono usate le repliche RPL_USERSTART, RPL_USERS,
RPL_ENDOFUSERS e RPL_NOUSERS. La replica RPL_USERSSTART
deve essere inviata per prima, seguita o da una
sequenza di RPL_USERS, oppure da una singola RPL_NOUSER.
Per ultima deve essere inviata una RPL_ENDOFUSERS.
200 RPL_TRACELINK "Link <version & debug
level> <destination> \ <next server>"
201 RPL_TRACECONNECTING "Try. <class> <server>"
202 RPL_TRACEHESHAKE "H.S. <class> <server>"
203 RPL_TRACEUNKNOWN "???? <class> [<client
IP address in dot form>]"
204 RPL_TRACEOPERATOR "Oper <class> <nick>"
205 RPL_TRACEUSER "User <class> <nick>"
206 RPL_TRACESERVER "Serv <class> <int>S<int>C
<server> \ <nick!user|*!*>@<host|server>"
208 RPL_TRACENEWTYPE "<newtype> 0 <client
name>"
261 RPL_TRACELOG "File <logfile> <debug
level>"
Le repliche RPL_TRACE* sono tutte inviate dal server
in risposta ad un messaggio TRACE. Quante ne vengano
inviate dipende dal messaggio TRACE e se questo
sia stato inviato da un operatore oppure da un normale
utente. Non c'è un ordine predefinito per quale
replica debba essere inviata per prima. Le repliche
RPL_TRACEUNKNOWN, RPL_TRACECONNECTING e RPL_TRACEHESHAKE
sono tutte usate per connessioni che non sono state
stabilite in maniera completa e risultano sconosciute,
oppure che sono ancora in corso di connessione,
oppure stanno completando il processo di 'server
handshake'. La replica RPL_TRACELINK è inviata da
qualsiasi server che tratta un messaggio TRACE e
deve passarlo ad un altro server. La lista di RPL_TRACELINKs
inviata in risposta ad un comando TRACE che attraversa
la rete IRC dovrebbe riflettere l'assetto effettivo
delle connessioni tra i server lungo quel percorso.
La replica RPL_TRACENEWTYPE deve essere usata per
ogni connessione che non rientra nelle altre categorie
ma viene comunque mostrata.
211 RPL_STATSLINKINFO "<linkname> <sendq>
<sent messages> \ sent bytes> <received
messages> \ <received bytes> <time open>"
212 RPL_STATSCOMMANDS "<Command> <count>"
213 RPL_STATSCLINE "C <host> * <name>
<port> <class>"
214 RPL_STATSNLINE "N <host> * <name>
<port> <class>"
215 RPL_STATSILINE "I <host> * <host>
<port> <class>"
216 RPL_STATSKLINE "K <host> * <username>
<port> <class>"
218 RPL_STATSYLINE "Y <class> <ping
frequency> <connect \ frequency> <max
sendq>"
219 RPL_ENDOFSTATS "<stats letter> :End
of /STATS report"
241 RPL_STATSLLINE "L <hostmask> * <servername>
<maxdepth>"
242 RPL_STATSUPTIME ":Server Up %d days %d:%02d:%02d"
243 RPL_STATSOLINE "O <hostmask> * <name>"
244 RPL_STATSHLINE "H <hostmask> * <servername>"
221 RPL_UMODEIS"<user mode string>"
Per rispondere ad una domanda sul mode di un client
viene inviata la replica RPL_UMODEIS.
251 RPL_LUSERCLIENT ":There are <integer>
user and <integer> \ invisible on <integer>
servers"
252 RPL_LUSEROP "<integer> :operator(s)
online"
253 RPL_LUSERUNKNOWN "<integer> :unknown
connection(s)"
254 RPL_LUSERCHANNELS "<integer> :channels
formed"
255 RPL_LUSERME ":I have <integer> clients
e <integer> \ servers"
Mentre processa un messaggio LUSERS, il server invia
degli insiemi di risposte dalla 251 alla 255. Mentre
risponde, il server deve inviare RPL_LUSERCLIENT
e RPL_LUSERME. Le altre risposte vengono inviate
solamente se viene trovato per loro un conteggio
diverso da 0.
256 RPL_ADMINME "<server> :Administrative
info"
257 RPL_ADMINLOC1 ":<admin info>"
258 RPL_ADMINLOC2 ":<admin info>"
259 RPL_ADMINEMAIL ":<admin info>"
Quando risponde ad un messaggio ADMIN, il server
è tenuto ad usare le repliche (dalla 256 alla 259)
elencate qui sopra e fornire un messaggio di testo
per ogni replica. Per la replica RPL_ADMINLOC1 il
server deve dare una descrizione di: città, stato
e paese in cui esso si trova, seguita da informazioni
sull'università e il dipartimento (RPL_ADMINLOC2)
e, per ultimo, il contatto amministrativo per il
server (è richiesto un indirizzo e-mail) nella risposta
RPL_ADMINEMAIL.
(15)
Torna all'indice
6.3 Risposte numeriche riservate.
Queste risposte numeriche non state descritte prima
in quanto esse rientrano in una delle seguenti categorie:
- non più in uso
- riservate per un prevedibile uso futuro
- correntemente in uso ma parte di un assetto
prestazionale non generale dell'attuale server
IRC.
209 RPL_TRACECLASS
217 RPL_STATSQLINE
231 RPL_SERVICEINFO
232 RPL_ENDOFSERVICES
233 RPL_SERVICE
234 RPL_SERVLIST
235 RPL_SERVLISTEND
316 RPL_WHOISCHANOP
361 RPL_KILLDONE
362 RPL_CLOSING
363 RPL_CLOSEEND
373 RPL_INFOSTART
384 RPL_MYPORTIS
466 ERR_YOUWILLBEBANNED
476 ERR_BADCHANMASK
492 ERR_NOSERVICEHOST
Torna all'indice
7. AUTENTICAZIONE DI CLIENT E SERVER
I client e i server sono soggetti allo stesso livello
di autenticazione.
Per entrambi, per ogni connessione fatta al server,
viene effettuato un passaggio dall'IP al nome della
macchina (ed un controllo all'inverso su questo).
Entrambe le connessioni sono poi soggette ad un
controllo sulla parola d'ordine (se ne è stata definita
una per quella connessione).
Questi controlli sono possibili su tutte le connessioni
sebbene il controllo sulla parola d'ordine sia usato,
in generale, solamente con i server.
Un controllo addizionale, che sta diventando sempre
più usuale, è il controllo sull'username (nome dell'utente)
responsabile della connessione. Trovare lo username
dall'altra parte connessa comporta la connessione
ad un server di autenticazione quale IDENT, come
viene descritto nel documento RFC 1413.
Dato che senza parole d'ordine non è cosa facile
determinare con sicurezza chi si trovi all'altro
capo di una connessione, l'uso delle parole d'ordine
è fortemente consigliabile nelle connessioni tra
server in aggiunta a misure di altra natura quale
l'uso di un ident server.
Torna all'indice
8. Implementazioni attuali
L'unica implementazione corrente di questo protocollo
è IRC server versione 2.8. [Ndr - Naturalmente questa
affermazione era valida al momento della pubblicazione
di questo documento nel maggio 1993: già al momento
di questa traduzione (giugno 1997) non lo è più].
(16)
Versioni precedenti potevano implementare in parte
o tutti i comandi descritti in questo documento,
sostituendo molte delle risposte numeriche con messaggi
NOTICE. Purtroppo, per esigenze di compatibilità
verso versioni precedenti, l'implementazione di
alcune parti di questo documento non è conforme
al modo in cui era stata progettata. Una differenza
notevole:
- il riconoscimento che ogni LF o CR che si
trovino in un qualunque punto di un messaggio
marchino la fine di quel messaggio (invece di
richiedere il CR-LF)
Il resto di questa sezione tratta argomenti che
hanno valore soprattutto per coloro i quali desiderino
implementare un server, ma alcune parti del protocollo
trovano un'utile e diretta applicazione anche ai
clients.
Torna all'indice
8.1 Protocollo Network: TCP - perchè esso trova
qui un applicazione ottimale.
L'IRC è stato implementato sulla base del TCP, dal
momento che il TCP fornisce un protocollo di rete
affidabile e che ben si adatta al tipo e dimensione
del sistema di scambio di messaggi cui IRC appartiene.
L'uso di IP multidirezionale costituisce un alternativa,
ma non è disponibile su vasta scala al momento.
Torna all'indice
8.1.1 Sostegno per Unix sockets
Dato che il campo d'azione degli Unix sockets permette
operazioni ascolto/connessione, l'implementazione
corrente può essere configurata in modo che essa
ascolti ed accetti le connessioni sia da client
che da server su un socket di dominio Unix. Queste
connessioni vengono riconosciute come socket quando
il nome dell'host inizia con il carattere '/'.
Quando il server fornisce delle informazioni sulle
connessioni socket di dominio Unix, esso deve sostituire
l'host name effettivo con il pathname, a meno che
non sia richiesto proprio il nome effettivo del
socket.
Torna all'indice
8.2 Analisi dei comandi
Per fornire un valido I/O (Input/Output) 'non-buffered'
in rete, sia per i client che per i servers, ad
ogni connessione viene assegnato un 'input buffer',
dedicato, nel quale sono memorizzati i risultati
delle operazioni di lettura e delle analisi di comandi
più recenti. è stata stabilita per il buffer un
ampiezza di 512 byte in modo che possa contenere
un messaggio completo, anche se, normalmente, contiene
più di un comando per volta. Il buffer dedicato
viene analizzato dopo ogni operazione di lettura
per verificare la presenza di comandi validi. Quando
accade di dover trattare nel buffer messaggi multipli
da un client, bisogna usare attenzione qualora un
messaggio causi la rimozione del client.
Torna all'indice
8.3 Invio del messaggio
É cosa molto comune trovare link della rete saturi
oppure macchine, alle quali si inviano dati, incapaci
di inviare dati. Sebbene Unix tratti questo problema
con la finestra TCP e buffer interni, il server
ha spesso enormi quantità di dati da inviare (specialmente
quando si forma un nuovo link server-server) ed
i piccoli buffer forniti nel kernel del sistema
operativo, non sono sufficienti per la lunga coda
di dati in uscita. Per alleviare questo problema
viene usato una "send queue" (sequenza di invio)
con i dati organizzati in una struttura FIFO. [Ndr
- Acronimo di First In, First Out, un modello di
organizzazione di dati] Una tipica "send queue"
può arrivare fino a 200 Kbyte di ampiezza in una
rete IRC di grandi dimensioni, con una connessione
alla rete lenta, quando un nuovo server si connette.
Nel raccogliere dati dalle sue connessioni, un server
in primo luogo leggera ed analizzerà tutte le informazioni
in entrata, mettendo in coda ogni dato da inviare
all'esterno. Quando tutti i dati in input disponibili
sono stati trattati, la sequenza di dati preparata
viene inviata. Questo riduce il numero delle chiamate
di sistema al comando write() (scrittura) e permette
al TCP il trattamento di pacchetti più grandi.
Torna all'indice
8.4 Connessione 'Liveness'
Per controllare quando una connessione si sia persa
oppure non risponda più, il server deve fare un
ping per ognuna delle sue connessioni dalle quali
non riceve risposte da un dato lasso di tempo.
Se una connessione non risponde in tempo, verrà
chiusa seguendo le procedure appropriate. Una connessione
viene fatta cadere anche nel caso in cui la sua
send queue (coda di dati da inviare) cresce al di
la del massimo consentito, in quanto è senz'altro
meglio chiudere una connessione lenta piuttosto
che il server si blocchi.
Torna all'indice
8.5 Stabilire una connessione server-client
Quando un client si connette ad un server IRC, gli
viene inviato il comando MOTD (se presente) come
del resto il numero di utenti e di server attualmente
connessi (come avviene per il comando LUSER). Viene
inoltre richiesto al server di fornire un messaggio
non ambiguo che notifichi al client il suo nome
e versione ed ogni altra informazione che possa
sembrare appropriata.
Dopo aver espletato queste funzioni, il server deve
inviare il nickname del nuovo utente e tutte le
altre informazioni fornibili da lui stesso (Comando
USER), come del resto le notizie reperibili in altra
sede (dai server con funzione di DNS/authentication).
Il server deve inviare queste informazioni con NICK
seguito da USER.
Torna all'indice
8.6 Stabilire una connessione server-server
Il procedimento usato per stabilire una connessione
server-server presenta aspetti particolarmente rischiosi,
in quanto ci sono innumerevoli circostanze nelle
quali è molto facile che vengano commessi errori
- il meno rilevante dei quali sono le cosiddette
"race conditions". [Ndr - Condizioni per la corretta
risoluzione delle quali la variabile tempo è di
importanza essenziale]
Dopo che un server ha ricevuto una connessione seguita
dalla coppia di comandi PASS/SERVER, riconosciuta
valida, il server dovrebbe rispondere con le sue
informazioni PASS/SERVER per quella connessione,
e con tutte le altre informazioni di stato che conosce,
come viene descritto qui di seguito.
Quando il server che inizia la connessione riceve
la coppia di comandi PASS/SERVER, anch'esso controlla
che il server che risponde sia autenticato in maniera
appropriata, prima di accettare la connessione con
quel server.
Torna all'indice
8.6.1 Scambio di informazioni di stato fra server
al momento della connessione
L'ordine delle informazioni di stato che vengono
scambiate tra server è essenziale. L'ordine richiesto
è il seguente:
- tutti gli altri server conosciuti;
- tutte le informazioni conosciute sugli utenti;
- tutti le informazioni conosciute sui canali.
Le informazioni riguardanti i server vengono inviate
mediante messaggi SERVER, le informazioni concernenti
gli utenti con messaggi NICK/UTENTE/MODE/JOIN e
le informazioni sui canali via messaggi MODE.
Nota: i topic dei canali *NON* vengono scambiati
in questa circostanza: il comando TOPIC cancella
ed aggiorna ogni informazione topic precedente,
cosicchè, nella migliore delle ipotesi, i due versanti
della connessione cambierebbero i topics. Passando
per prime le informazioni di stato dei servers,
tutte le collisioni tra server che gia esistano
hanno luogo prima che possano aver luogo le collisioni
sui nick dovute al fatto che un secondo server introduce
un nick che gia esista su un altro). Dal momento
che la rete IRC è capace di esistere solo come un
grafo aciclico, potrebbe essere possibile che la
rete si sia gia riconnesso in un altra locazione:
il luogo dove avviene la collisione tra server indica
allora il luogo dove la rete necessita di uno split.
Torna all'indice
8.7 Terminazione di connessioni server-client
Quando una connessione client chiude, viene generato
un messaggio QUIT, ad interesse del client, dal
server al quale il client era connesso. Non è necessario
generare od usare altri messaggi.
Torna all'indice
8.8 Terminazione di connessioni server-server
Se una connessione server-server viene chiusa, che
sia per un messaggio remoto SQUIT sia per cause
'naturalì, il resto della rete IRC connessa deve
essere informata della sconnessione dal server che
ha scoperto la chiusura che invierà una lista di
SQUIT (una per ogni server che si trova oltre la
sconnessione) ed una lista di QUIT (una per ogni
client nella stessa posizione).
Torna all'indice
8.9 Seguire la traccia dei cambi di nickname
Tutti i server IRC devono tenere una traccia storica
dei cambi recenti di nick. Questo è richiesto per
permettere al server di avere una possibilità di
restare in contatto con la situazione quando cambi
di nick si succedano a gran velocità (race conditions)
insieme con comandi che trattano i nick stessi.
I comandi che devono tener traccia dei cambi di
nick sono:
- KILL (il nickname ha subito un KILL)
- MODE (+/- o,v)
- KICK (il nickname subisce dei KICK)
Per nessun altro comando devono essere controllati
i cambi di nick.
Nei casi sopra descritti, al server è richiesto
innanzi tutto di controllare l'esistenza del nick,
e poi di controllarne la storia per vedere a chi
appartiene al momento (sempre se qualcuno stia usando
quel nickname !). Questo riduce le possibilità di
trovarsi in situazioni difficoltose a causa della
velocità con cui si succedono le operazioni (race
conditions), ma difficoltà possono comunque verificarsi
qualora il server finisca per eseguire il comando
su un client sbagliato. Quando si attua il tracciamento
per i cambi di nickname, come descritto qui sopra,
si raccomanda che venga concesso un intervallo di
tempo e che vengano ignorati casi troppo vecchi.
Per avere un archivio storico ragionevole, un server
dovrebbe essere in grado di tenere i nick precedenti
di ogni client che conosce, qualora tutti decidessero
di cambiare. l'ampiezza dell'archivio storico è
comunque limitata da fattori diversi (per esempio
dalla disponibilità di memoria, ecc.).
Torna all'indice
8.10 Controllo del flood dei clients
Con una grande rete IRC di server interconnessi,
è molto facile per qualsiasi client connesso alla
rete, di produrre un flusso continuo di messaggi
che finisce non solo per floodare [Ndr - flood vale
allagamento, alluvione, inondazione] la rete, ma
anche per degradare il livello delle prestazioni
erogate verso gli altri clients.
Piuttosto che richiedere ad ogni possibile vittima
di provvedere alla propria protezione, la protezione
flood è stata scritta nel server ed applicata a
tutti i client tranne che ai servizi.
L'algoritmo adottato segue il seguente schema:
- controlla se il 'message timer' segna un tempo
precedente rispetto all'orario corrente (aggiornarlo,
se necessario, per renderlo uguale al tempo
corrente);
- leggere ogni dato presente proveniente dal
client;
- mentre il timer è avanti di meno di dieci
secondi dall'orario corrente, analizza ogni
messaggio presente, e penalizza il client di
2 secondi per ogni messaggio;
il che significa, di fatto, che il client può mandare
1 messaggio ogni 2 secondi senza subire penalità.
Torna all'indice
8.11 Letture veloci per evitare blocchi
In un ambiente real-time, è essenziale che tutte
le azioni dei server attendano il minor tempo possibile
per essere espletate, cosicchè tutti i client siano
serviti in modo equo. Ovviamente questo richiede
un non-blocking I/O su tutte le operazioni read/write
del network. Per le connessioni server normali,
questo non sarebbe difficile, ma ci sono altre operazioni
di supporto che possono causare il blocco temporaneo
del server (quali la lettura dei dischi). Dove possibile,
una tale attività dovrebbe essere espletata con
pause di funzionamento brevi.
Torna all'indice
8.11.1 Lettura veloce dell'Hostname (DNS)
l'uso delle librerie di Berkley e di altre, per
la risoluzione degli indirizzi, comportava lunghi
tempi di elaborazione ed in alcuni casi le risposte
arrivavano fuori tempo massimo. Per evitarlo sono
state scritte delle routine alternative per la risoluzione
dei DNS, predisposte per operazioni di I/O che non
comportano pause di funzionamento, e da cui si raccolgono
dati nell'ambito del loop di I/O principale del
server.
Torna all'indice
8.11.2 Lettura veloce dell'Username (Ident)
Tutte le numerose librerie di identificazione che
ci sono a disposizione, adatte ad essere incluse
ed adoperate all'interno di altri programmi, hanno
causato inconvenienti legati al fatto che operano
in maniere sincrona, causando ritardi notevoli e
frequenti. Ancora una volta la soluzione è stata
quella di scrivere degli insiemi di routine capaci
di cooperare in maniera efficiente con il resto
del software dei server usando funzioni di I/O che
non comportano pause di funzionamento.
Torna all'indice
8.12 File di configurazione
Per fornire un modo flessibile per configurare e
far funzionare il programma server, è auspicabile
l'impiego di un file di configurazione che contenga
istruzioni per il server sugli aspetti seguenti:
- da quali host accettare connessioni da client;
- quali host autorizzare a connettersi come
servers;
- a quali host possa connettersi (sia in modo
attivo che passivo);
- informazioni sulla collocazione del server
(per esempio: università, città/stato, azienda);
- chi sono i responsabili per quel server ed
un indirizzo e-mail dove possano essere contattati;
- hostname e parola d ordine per quei client
ai quali si desidera che sia dato accesso ai
comandi riservati agli operatori.
Nello specificare gli hostname, sia il domain name
(composto da caratteri alfabetici) sia l'uso della
'notazione numerica' (127.0.0.1) dovrebbero essere
accettati. Deve essere possibile specificare la
parola d ordine che deve essere usata / accettata
per tutte le connessioni in entrata ed in uscita
(malgrado le uniche connessioni in uscita siano
quelle verso altri server).
La lista precedente è il minimo richiesto per un
server che desideri fare una connessione con un
altro server. Altre voci che potrebbero essere utili
sono:
- quali server altri server possono introdurre;
- profondità permessa ad una ramificazione del
server;
- l'orario durante il quale i client si possono
connettere.
Torna all'indice
8.12.1 Permettere ai client di connettersi
Il server dovrebbe usare qualcosa come una 'lista
di controllo di accessò (contenuta nel file di configurazione
oppure altrove) che venga letta all'accensione ed
usata per decidere quali host possano usare i client
per connettersi. Sia la dichiarazione 'deny' (negato)
che 'allow' (permesso) dovrebbero essere implementate
per fornire la flessibilità necessaria per il controllo
di accesso degli hosts.
Torna all'indice
8.12.2 Operatori
Concedere i privilegi di operatore ad una persona
che distruttiva, può avere conseguenze gravi per
il buon funzionamento della rete IRC, proprio a
causa dei poteri che a quella persona vengono attribuiti.
Cosi l'acquisizione di questi poteri non dovrebbe
essere cosa facile. La configurazione corrente richiede
l'uso di due parole d ordine, sebbene unadi esse
sia di solito facilmente intuibile. Se si memorizzano
le parole d'ordine per gli operatori nei file di
configurazione è consigliabile codificarle ed immagazzinarle
in un formato criptato (per esempio usando il crypt(3)
di Unix) per prevenire facili ruberie.
Torna all'indice
8.12.3 Permettere ai server di connettersi
l'interconnessione di server non è una cosa banale:
una cattiva connessione può avere una grande influenza
sull'efficienza di IRC: cosi ogni server dovrebbe
avere una lista di server ai quali possa collegarsi,
e di server che possono collegarsi con lui. Per
nessuna ragione o circostanza un server dovrebbe
permettere ad un arbitrario host di connettersi
come server. In aggiunta alla lista di server che
possono e non possono connettersi, il file di configurazione
dovrebbe anche contenere la parola d ordine ed altre
caratteristiche di quel link.
Torna all'indice
8.12.4 Administrivia
Per fornire delle risposte valide ed accurate al
comando ADMIN (si veda la
sezione 4.3.7),
il server dovrebbe trovare i relativi dettagli nel
file di configurazione.
Torna all'indice
8.13 Associazione ai Canali
Il server corrente permette ad ogni utente locale
registrato di associarsi ad un numero massimo di
10 canali. Non c'è limite imposto ad utenti non
locali, cosi che il server rimane (ragionevolmente)
coerente con tutti gli altri per quanto riguarda
l'associazione ai canali.
Torna all'indice
9. PROBLEMI CORRENTI
Vi sono un certo numero di problemi già rilevati
su questo protocollo, che si spera possano essere
risolti in un prossimo futuro riscrivendo il software.
Attualmente sono in corso tentativi per trovare
delle soluzioni efficienti per questi problemi.
Torna all'indice
9.1 Adattamento a situazioni di dimensioni rilevanti.
É riconosciuto ampiamente che questo protocollo
non si adatta sufficientemente bene quando opera
su larga scala. Il maggior problema viene dalla
necessità che tutti i server sappiano di tutti gli
altri server ed utenti e che le informazioni che
li riguardano siano aggiornate non appena subiscono
cambiamenti. É inoltre desiderabile tenere basso
il numero dei servers, così che la lunghezza del
percorso tra due punti sia la più breve [Ndr - Evidentemente
in termini di numero di nodi intermedi] e che l'albero
della rete il più ramificato possibile.
Torna all'indice
9.2 Etichette
l'attuale protocollo IRC prevede tre tipi di etichette:
il nick, il none del canale ed il nome del server.
Ognuno di questi tipi ha il suo ambito di validità
specifico e non sono permessi duplicati all'interno
di quell'ambito. Attualmente è possibile per gli
utenti scegliere un'etichetta in ognuno dei tre
ambiti, con la possibilità di creare collisioni.
è chiaro a molti che questo problema pone la necessità
di una revisione, con un piano di nomi unici che
non collidano, per canali e nicks. Altrettanto desiderabile
appare una soluzione che permetta un organizzazione
ad albero ciclico per la rete.
Torna all'indice
9.2.1 Nicks
L'idea dei nick su IRC è molto conveniente da usare
per gli utenti che parlano gli uni con gli altri
fuori da un canale, ma c'è solamente uno spazio
finito per i nick come ci si poteva tranquillamente
aspettare, non è inconsueto che più persone vogliano
usare lo stesso nick. Se un medesimo nickname viene
scelto da due persone che usano questo protocollo,
o una delle due non riuscirà nel suo intento, oppure
tutte e due saranno rimosse con l'uso di KILL (4.6.1).
Torna all'indice
9.2.2 Canali
l'attuale organizzazione dei canali richiede che
tutti i server siano a conoscenza di tutti i canali,
dei loro membri e delle loro proprietà. Otre al
non perfetto adattamento alle varie condizioni dimensionali
della rete, anche la questione della privacy costituisce
un problema preoccupante. Una collisone di canali
viene trattata come un evento inclusivo (entrambe
le persone che creano un canale sono considerate
membri di esso) piuttosto che come un evento esclusivo,
del tipo di quello usato per risolvere la collisione
fra nicks.
Torna all'indice
9.2.3 Servers
Sebbene il numero dei server sia di solito piccolo,
se rapportato al numero di utenti e di canali, devono
pero essere conosciuti globalmente, o separatamente
uno per uno oppure compresi dentro uno schema (mask).
Torna all'indice
9.3 Algoritmi
In qualche circostanza, nel software per il server,
non è stato possibile evitare gli algoritmi di ordine
N^2 quali il controllo della lista di canali di
un insieme di clients. Nell'attuale versione del
server non sono compresi controlli sulla coerenza
dei database: ogni server presume che il suo vicino
sia corretto. Questo spalanca le porte a molti problemi
se un server che si connette ha dei bug oppure introduce
contraddizioni nella rete esistente.
A causa della mancanza di garanzia dell'unicità
per le etichette interne e globali, si danno molto
spesso dei problemi di coordinamento temporale (race
condition). Queste condizioni hanno generalmente
origine dalfattoche i messaggi impiegano del tempo
per percorrere la rete IRC ed avere effetto su di
essa. Anche se si cambia scegliendo un sistema unico
di etichette, rimane aperto il problema inerente
i comandi relativi ai canali che vengono perduti.
Torna all'indice
10. SUPPORTO E DISPONIBILITÁ
Mailing list per discussioni relative a IRC:
Protocollo futuro:
ircd-three-request@eff.org
Discussione generale:
operlist-request@eff.org
Implementazioni software:
cs.bu.edu:/irc
nic.funet.fi:/pub/irc
coombs.anu.edu.au:/pub/irc
Newsgroup:
alt.irc
Torna all'indice
11. CONSIDERAZIONI SULLA SICUREZZA
La sicurezza è discussa nelle sezioni
4.1,
4.1.1,
4.1.3,
5.5,
e
7.
Torna all'indice
12. INDIRIZZI DEGLI AUTORI
NOTE
(redatte da Francesco
Messineo)
(1) - Ci si riferisce a
4 anni trascorsi all'epoca del rilascio della RFC
originale: l'età al momento attuale (1977) di IRC
supera gli 8 anni.
Torna al testo
originale
(2) - Questo documento non descrive esattamente
il protocollo IRC attualmente utilizzato (1977),
ma non risultano esistere documenti successivi e
più aggiornati così ampi e comprensivi.
Torna al testo
originale
(3) - Sembra che le attuali versioni dei
server non permettano comunque l'accesso a più di
10 canali, ma esistono diverse versioni sulla stessa
rete che si comportano in modo diverso.
Torna al testo
originale
(4) - "Socket", come "file", non si traduce
in italiano, di solito. In parole molto povere,
un socket è un "file di rete" cioè corrisponde ad
un canale e non a dei dati su una memoria di massa,
ma può essere letto e scritto come un file.
Torna al
testo originale
(5) - Alle tre precedenti dovrebbe essere
aggiunta la seguente condizione: 4. se il canale
è +l il numero massimo di utenti sul canale non
deve essere raggiunto (o superato).
Torna al
testo originale
(6) - Dovrebbe (anzi di solito lo è ) essere
data anche la RPL_NAMEREPLY.
Torna al
testo originale
(7) - Non sembra facile poter pensare ad
una trasformazione di IRC senza nicknames.
Torna al
testo originale
(8) - Questi modi ormai non riflettono più
quelli attualmente disponibili nelle attuali versioni
usate su IRCNet.
Torna al
testo originale
(9) - Anche questi modi non corrispondono
esattamente a quelli attualmente in uso su IRCNet:
tanto per fare un esempio, non esiste più il modo
"s" ed esiste il famigerato modo "r".
Torna al
testo originale
(10) - L'estensione del comando non dovrebbe
più essere possibile con le nuove versioni del server
IRCNet.
Torna al
testo originale
(11) - I server attuali rispondono ad un
numero abbastanza maggiore di richieste, ad esempio:
"/stats z", "/stats d", "/stats t".
Torna al
testo originale
(12) - Attualmente anche un operatore può
vedere gli utenti connessi solo al suo server. Nelle
precedenti versioni, gli operatori potevano effettivamente
vedere gli utenti anche su altri servers.
Torna al
testo originale
(13) - Il /whois si comporta in maniera leggermente
differente in realtà vengono visualizzate tutte
le informazioni solo se il nick richiesto è sullo
stesso server di chi esegue il comando, altrimenti
vengono visualizzate solo le informazioni generali
(nick, hostname e servername).
Torna al
testo originale
(14) - Il commando SUMMON è ormai disabilitato
quasi su ogni server.
Torna al
testo originale
(15) - Per ottenere un elenco completo delle
risposte numeriche e del loro significato è opportuno
fare riferimento direttamente ai sorgenti della
versione del programma server alla quale si è interessati.
- Se la memoria non mi abbandona, si trovano nel
file "numerics.h".
Torna al
testo originale
(16) - La versione attuale è la 2.9 e la
2.9.2p2 quella maggiormente usata.(Giugno '97)
Torna al
testo originale