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

5. MESSAGGI FACOLTATIVI

Questa sezione descrive i messaggi FACOLTATIVI. Essi non sono richiesti in una implementazione server attiva del protocollo descritto in questo documento. Se il trattamento di un messaggio opzionale non è implementato, deve essere generato un apposito messaggio di errore oppure un errore generico di comando sconosciuto. Se il messaggio è destinato ad un altro server deve essere passato oltre (è richiesta una analisi elementare). Le risposte numeriche adatte allo scopo sono elencate con i messaggi descritti qui di seguito.

Torna all'indice
5.1 Messaggio AwayComando: 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:

  1. non più in uso
  2. riservate per un prevedibile uso futuro
  3. correntemente in uso ma parte di un assetto prestazionale non generale dell'attuale server IRC.
209 RPL_TRACECLASS
217 RPL_STATSQLINE
231 RPL_SERVICEINFO
232 RPL_ENDOFSERVICES
233 RPL_SERVICE
234 RPL_SERVLIST
235 RPL_SERVLISTEND
316 RPL_WHOISCHANOP
361 RPL_KILLDONE
362 RPL_CLOSING
363 RPL_CLOSEEND
373 RPL_INFOSTART
384 RPL_MYPORTIS
466 ERR_YOUWILLBEBANNED
476 ERR_BADCHANMASK
492 ERR_NOSERVICEHOST


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

Jarkko Oikarinen Darren Reed
Tuirantie 17 as 9 4 Pateman Street
90500 OULU Watsonia, Victoria 3087
FINLE Australia
Email: jto@tolsun.oulu.fi Email: alon@coombs.anu.edu.au

NOTE

(redatte da Francesco 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


Torna all'indice



  Ultime dal forum IRC
  Ultimi File Inseriti
Diablo III (14624)
Fancazzista Scr... (18764)
Sensuality scri... (7622)
Grand Theft Aut... (5154)
Stealth Script ... (8382)
-SagittarioScri... (18835)
Paradise Script (13753)
Trivia Game 200... (11882)
Ircap Script 8.... (5191)
RawScript 2.0 (8481)


 

 


Cerca nel sito

Le ultime news:

Ultimi commenti
1
1
1


Sondaggio
Cosa vorresti di nuovo?

Risultati | Archivi

Statistiche Download
Database:
283 Files
241 Mb
Scaricati:
2659868 Files
Totale: 5615348Mb

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