ARGOMENTO:

Venturini Dario
Personalmente credo che IRC sia praticamente morto. Inoltre.. boh. Non mi ci trovo tanto bene, la messaggistica istantanea mi sembra più comoda.
...
A breve avremo un raduno fisso su Teamspeak, un software per le chat vocali. In cantiere abbiamo una newsletter, di standard c'è il forum, Facebook (bacheca di discussione per il gruppo), MSN, skype, ICQ e altri client IM per chi li ha messi nel profilo.

Croxarens
Secondo me, un canale IRC è utile, specialmente se si danno degli appuntamenti, magari per parlare di un progetto in particolare.. E credo sarebbe interessante anche una guida su come utilizzare il canale IRC, in modo da poter venire in "soccorso" a chi non sa utilizzare bene IRC.

crono
io credo tutto sia utile se ben supportato.
tutto dipende dalla "voglia" degli utenti iscritti alla community di partecipare e di utilizzare questo tipo di IM.
sono d'accordo se c'è un buon numero di partecipanti disposti a connettersi assiduamente su irc.

IRC come lo conosciamo oggi è l' evoluzione del programma talk (che permetteva la comunicazione 1-1 su Internet ma mancava della feature di comunicazione di gruppo la cosiddetta comunicazione a 3 vie) per cui Jarkko Oikarinen in Oulu University (Oulu è una piccola città nella costa NE di Finlandia) per ottemperare alla 3za via di comunicazione scrisse parecchio codice nell' estate del 1988. Ancor oggi in Oulu esiste un server locale IRC col nome originale (che usò Oikarinen) "oulubox".

Come Popolarità IRC arrriva dopo Email(architettura con federazione) e WWW(architettura senza federazione). Col tempo la sua complessità ha aumentato tanto che mantenerlo e usarlo non è più banale e richiede dai suoi utenti conoscenze tecniche superiori alla media della maggioranza delle applicazioni Web.

IRC diventò operativo nel 1988 con pochi utenti i quali erano pure gli sviluppatori del software e delle regole che adesso formano la fondazione IRC. Nei primi anni 90 cominciarono ad usarlo istituzioni educazionali da tutto il mondo facendo schizzare la sua popolarità a 5000 connessioni simultanee nel 1992. Allora qualcuno esclamò che IRC ha raggiunto il suo limite. Nel 1999 la maggior parte degli utenti furono accademici e la EFnet , la più grande rete IRC allora, si fregiava di 50000 connessioni simultanee che con gli anni a venire crebbe esponenzialmente.

La politica ha fatto la sua presenza nella comunità IRC molto presto ed era evidente che non tutti avevano la stessa visione per il futuro a venire. Si sono fatti moltissimi cambiamenti dal IRC originale(adesso conosciuto come IRCnet ) e c'è il problema che le diverse reti IRC che sono venute fuori malgrado aderiscano allo stesso protocollo base (IRC) seguono diversi standards(insieme di metodi) tecnico-amministrativi anziché seguire un' unica strada. Questa frammentazione del mondo IRC in tante entità separate si ripercuote a livello utente finale ancor oggi.
Quindi anziché avere un' unica e grandissima rete IRC nel modo ne abbiamo molte di più e più piccole. Dal punto di vista utente si deve avere una mappa di tutte queste reti per non perdersi.

Tutte queste reti distinte IRC ricadono in 4 categorie:

1. Le "Metropoli"(in funzione delle loro dimensioni):EFnet, IRCnet, Undernet, e DALnet. Ogni utente IRC li visiterà prima o poi. Hanno molti utenti da tutto il mondo
2. Le "Piccole città": ove regna più ordine e legge: le più grandi a questo livello sono : "Talk City" e "Microsoft Chat Network". Sono meno cosmopolitici rispetto ai grandi network. E' nei piccoli villaggi della mappa IRC che la gente si conosce di più e i newbies si sentono più a proprio agio e più sicuri. Non a tutti piace il caos delle metropoli. Molti di questi piccoli networks offrono un servizio di registrazione e hanno "strict policies" sui loro "topic". Molti di essi stanno negli USA e offrono un posto di conversazione piacevole per loro e i loro figli.
3. "Reti locali/regionali" molte delle quali si basano sulla lingua(solitamente diversa dall' inglese) e servono un certo stato o hanno servers in diversi stati che parlano quella lingua. Sono molto frequentati sia dai locali sia dagli espatriati. Le più grandi(hanno parecchie decine di migliaia di utenti regolari) di tali reti sono in Brasile, Spagna, Portogallo, Australia. reti più piccole stanno in Messico, Italia, Turchia, Grecia, Bulgaria, Ex republiche Sovietiche, e Sud-Africa.
   In altri stati i servers locali si connettono sulle "reti città" ma sono molto usati dagli utenti locali. E' il caso degli stati Nordici, Giappone, Polonia, Italia ed altri ove molti servers esistono come parte di una rete più grande(principalmente IRCnet)
4. "Reti orientate a interessi specifici particolari" che non ricadono nelle 3 categorie precedenti. Nessuna di esse è molto grande a causa del fatto che in pratica non hanno attività al di fuori della propria area di interesse ufficiale. I topics più popolari riguardano computers, operating systems, etc. Altri sono rivolti a bambini, offrono un ambiente più protetivo sotto supervisione degli adulti. Molti servizi in questa quarta categoria sono stand-alone servers anzichè vere e proprie reti di servers.

La parola chiave in IRC(Internet Relay Chat) è l' acronimo mediano: "Relay". In primis IRC ha un' architettura client-server. Certo per uno che sviluppa programmi client e addons non è assolutamente necessario usare un client IRC(inteso come programma a parte. Invece si può collegare semplicemente usando telnet ) ma un client automatizza molte delle procedure necessarie per far stare in piedi il collegamento client-server IRC oltre a offrire una interfaccia comoda e semplice server-utente nascondendo molti messaggi tecnici scambiati fra server e client(p.e. il client manda dei PONG in risposta ai PING del server). Neanche gli esperti ormai fanno a meno dell' uso di un client IRC. Tradizionalmente i più rappresentativi sono mIRC , Xchat per il mondo Microsoft(ricco, e dotato di diverse utilità), ircII , irssi per Unix (scarno, flessibile, veloce) e ircle per i Mac.

I server IRC sono connessi fra loro in una rete oltre ad essere connessi ognuno con un proprio insieme di client. Facciamo un esempio:
Supponiamo che Harry collegato al serverA(che per Harry è un server di accesso alla rete IRC) vuol mandare un messaggio a Dan che è invece collegato a un server diverso serverB(che per Harry è un server di accesso alla rete IRC). Come vediamo Harry e Dan non sono connessi direttamente fra loro ma indiretttamente tramite i loro(di solito i servers appartengono a 3ze parti) servers di accesso alla rete IRC. Non dimentichiamo anche che serverA e serverB sono connessi fra loro.

1. Quindi Harry manda il messaggio al suo serverA. Tale messaggio conterrà oltre al messagio vero e proprio anche il destinatario (Dan). Quindi il serverA conosce
a) che c'è Dan sebbene Dan non sia connesso direttamente con lui.
b) che Dan è connesso col serverB

2. Il serverA inoltra --relay-- il messaggio di Harry verso il serverB. Ma prima di inoltrarlo salva in esso il nome del client mandante (Harry) cosi il ricevente(Dan) saprà chi gli manda il messaggio (Harry)

3. il serverB vede dal messaggio che chi deve riceverlo (Dan) è uno dei suoi client. Quindi inoltra il messagio a Dan il quale può leggerlo.

Il perché di una rete di servers anziché un unico grande server oltre che per ragioni di ridondanza(se l'unico server "cade" cade tutto il sistema di comunicazione, d' altro canto un unico server sarebbe più facilmente manutenibile però)è dovuto semplicemente per aumentare l' efficienza nella comunicazione ossia permette all' utente di collegarsi attraverso un server fisicamente vicino(che avrà il minore PING round trip possibile) questo serve per aumentare la velocità di comunicazione nel link utente-server e considerando il link server-server (che sicuramente sarà molto più efficiente del link(collegamento) user-server) come una costante alla fine aumenterà l' efficienza globale di tutto il sistema.
Inoltre maggiore è il numero di servers interconnessi che fa parte di una rete IRC(o altra) più versatile è tale rete. P.e. l' utente può collegarsi con uno qualsiasi di loro.

Il trasferimento del messaggio fra i servers e i loro clients ha una durata tipica dell' ordine di msec(millesimi di secondo). Ossia lo scambio messaggi fra le parti simula benissimo quello di una reale conversazione. Questa è la ragione principale perché Harry e Dan non debbano per forza essere connessi direttamente(logicamente il collegamento diretto è più veloce di uno attraverso intermediari) per poter scambiare i loro messagi. L' ambiente IRC permette di mandare uno stesso messaggio contemporaneamente a un numero virtualmente illimitato di destinatari con un minimo dispendio di risorse. Questo è il punto forte di IRC quello che lo ha fatto diventare famoso.

Nel continuare coll'esempio precedente supponiamo che al serverB oltre a Dan sia connesso adesso anche Kev e tutti e 3 Harry, Dan, Kev si siano riuniti(join in gergo IRC) nel channel boinc-it il quale fa da mezzo per una comunicazione a 3 vie. Quindi se Dan vuole mandare un messaggio a Kev lo manda al canale anziché mandarlo solo a Kev in modo da poterlo ricevere tutti quelli attualmente collegati al canale.

Non è necessario che il sistema client-server IRC sia connesso ad Internet. Esso può essere benissimo confinato(isolato) dentro una LAN

I clents si possono distinguere riguardo:

1. la UI: ci sono clients orientati alla GUI e pochi ormai orientati alla linea di commando
2. Esistenza o meno di un linguaggio di scripting che aumenta le features che da di default il client

Ci sono clients multipiattaforma, o inizialmente sviluppati per una piattforma e successivamene portati ad altre, oltre che monopiattaforma.
Tutti i clients tendono ad avere un insieme standard di commandi base(conformi a ircII, il primo client usato ampiamente)

I clients racchiudno 2 insiemi di commandi. Il primo serve per communicare col server il 2ndo non mappa neccessariamente(dipende dai skill dell' autore del client o dalla sua decisione che alcuni cmds non sarebbero utili all' utente finale) tutti i cmds del primo insieme sulla UI(2ndo insieme di cmds). La UI serve all' utente per controllare il primo insieme di commandi.
Inoltre gli UI cmds sono in continua espansione mentre i server cmds hanno un passo molto più lento. Un UI cmd puo seere mappato 1-1 o 1-n(un Ui cmd espande in n server cmds)
Esempio:
PART è un server cmd e molti client permettono di inserirlo direttamente. Qualche sviluppatore ha introdotto nel suo client il cmd LEAVE che fa esattamente lo stesso lavoro. Siccome il set di cmds lato srerver non comprende LEAVE quando noi digitiamo PART o LEAVE nel client esso mappa(si traduce) sempre come PART. Quindi se si è interessati(p.e. per scrivere addons per il client) a imparare dei commandi conviene imparare l' insieme dei commandi del server(anzichè del client)

Dopo che IRC si frammentò i software server( ircd ) per ogni rete si sviluppò senza un coordinamento introducendo features e commandi propri. L' utente può ottenere tutte queste informazioni dopo essersi connesso alla specifica rete. Quindi può capitare che uno stesso commando abbia semantica diversa in reti diverse o che un commando funzioni(esista) in una rete ma non in un altra.

Per far capire al client che ciò che immettiamo è un commando anzicchè un messaggio si usa preporgli un carattere speciale(si chiama carrattere di commando) "/"(Il client poi manda il commando al server senza la "/"). Non ci deve essere spazio fra "/" e commando --altrimenti i risultati possono essere inaspettati-- ma ci deve essere fra commando e parametri. I parametri possono essere obbligatori o opzionali dipende dal particolare commando.

La sinassi nella forma generale è:

<command character> COMMAND <parameters to the command>

I commandi sono case-insenitive

Core commands

Il server IRC manda un messaggio se il proprio nick è già in uso o contiene caratteri non accettabili.
• 1. Il primo carattere non può essere un numero o "-"
• 2. [a-z, A-Z, 0-9, \, ^, -, |, _, `] sono validi
• 3. le coppie di caratteri [],{}, |\ corrispondono in una stessa lettera maiuscola-minuscola nella tastiera Scandinava(ricordiamo che IRC nacque in Scandinavia) e siccome IRC è case-insenitive queste copie si caratteri si considerano come un unico carattere

Gli utenti in IRC possono conoscerci in due modi differenti.
Il primo modo è tramite il nostro nickname attraverso il quale ci possono vedere e cercare su IRC. Il nick viene inoltre usato come indirizzo destinazione per messaggi e come identificatore per le richieste (riguardanti noi) al server.
Il secondo modo è più complesso e consiste di 3 parti:Il nostro hostname in alternativa può essere l' indirizzo IP da dove ci colleghiamo(l' IP che ci assegna il nostro ISP).

Quindi ricapitolando la nostra identità che il client manda al server è "Nickname!Questo indirizzo email è protetto dagli spambots. È necessario abilitare JavaScript per vederlo.". Se noi mandiamo un messaggio destinato a un altro utente o a un altro server la nostra identità viene inoltrata insieme al messaggio. La nostra identità si chiama user mask in IRC

Se la rete a cui ci colleghiamo ha un servizio nickname(solitamente il nickname di tale servizio si chiama NickServ) possiamo riservare in esclusiva un nick tutto per noi. Dipende poi dalle caratteristiche del servizio può essere perrmesso o impedito ad altri di usare il nostro nick in nostra assenza o immettere informazioni personali alla nostra registrazione che gli altri posssono vedere.
Il commando:ci fa vedere il come si può usare. Nel qualcaso capita di usare un nick registrato a qualcun altro e il proprietario del nick ha istruito il server di impedire l' uso del suo nick da altri utenti il server ci manderà una notifica (che il nick è riservato e noi o dobbiamo cambiarlo entro un minuto p.e. o il servizio ci farà "kill" ossia ci scollegherà per uso non autorizzato del nick) subito dopo il collegamento e noi dobbiamo agire solitamente entro un certo tempo o assumerà il nickname.
ATTENZIONE Se invece riceviamo un notifica del genere in una rete che a priori sappiamo non avere un Nickserver vuol dire che qualcuno ci vuole fregare il nick per usarlo. Quindi lo dobbiamo ignorare.


•Il campo Realname(Full name)



•Il campo Username



•I campi nickname alternative



•Il campo Email Address

Tutti i server permettono all' utente di controllare lo stato della sessione attrraverso gli "user modes". Essi possono variare molto in numero e funzione da server a server. Per impostere(+ o non mettere niente) o eliminare(-) da soli un "user mode":
I caratteri che rappresenteno i "user modes" sono case-sensitive

Ci sono un sacco di Umodes(nessuno di essi è di interesse per un utente medio) usati dagli IRC ops per monitorare il server. Inoltre la semantica di un umode può essere diversa da server a server. "i, o, s, e w" solo i soli che hanno lo stesso comportamento su quasi tutti i servers. Gli umodes più interessanti su piccole reti sono "x, a, or z(dipende dalla rete)". Il server può impostarli automaticamente.


•Umode i (invisible)



•Umode w (messaggi rivolti solo per gli "IRC ops")



•Umode s (messaggi che non interessano l' utente regolare)



•Umode o (solo per gli "IRC ops")



•Umode d (dumb)



•Umode r (restricted)


ATTENZIONE

Quando ci colleghiamo a un server non siamo obbligati a usare lo stesso server per tutta la nostra sessione in IRC. Tutti i clients supportano il commando(che appartiene all' insieme dei commandi del server) SERVER attraverso cui noi possiamo cambiare server(opzionalmente anche la porta):oppureQualche client come MIRC permette arrtaverso un bottone connect-diconnect di disconnetersi prima e poi dalla lista dei server sceglierne un altro. In ircII puoi scegliere un server da una lista interna di servers. Ad ogni modo due cose possono accadere(dipende dal client usato):
•Il client chiude la connessione col server attuale e inizia una nuova con un altro server
•Il client tiene la vecchia connesione finchè la nuova connesione non acquista stato "established"
Tutto ciò ha a che fare con la connessione TCP una volta che essa viene stabilita la vecchia connessione viene chiusa anche se il nuovo server ci impedisce l' accesso

Vediamo come funziona in ircII: Ogni server di cui noi tentiamo l' accesso si mette in una lista e si assoccia con un numero. Col commando "/server" possiamo vedere tale lista. Noi possiamo usare tale numero anzichè il nome del server. Possiamo anche immettere nella lista interna, dei server di default quando eseguiamo ircII con lo switch -a

Ad ogni stante ci possiamo disconnettere dal server attraverso il cmd QUIT.Dipende dal client c'è più di un sinonimo di QUIT: BYE, EXIT, o SIGNOFF. A volte QUIT chiude pure il client. In un client grafico si ottiene lo stesso risultato chiudendo la finestra di stato(la finestra su cui spuntano messaggi dal server IRC non quella dei messaggi) anche se cosi non ci viene confermata la chiusura della connessione dalla parte del server. Invece attraverso QUIT si ha una disonnessione con tutti i crismi permettendo al server sapere in tempo reale che noi non ci siamo più. Altrimenti il server farà un bel po per capire che la nostra connesione non esiste più.
QUIT può essere accompagnato con testo arbitrario(saluto o "signoff reason") di solito limitato a un certo numero di caratteri (sui 70 di solito). Altrimenti o non manda nessun testo al server o manda un testo di default p.e. "Leaving".QUIT chiude tutti i canali a cui partecipiamo. Quindi non è neccessario chiudere il canale prima di lasciare IRC. I server ops in molte reti monitorano i QUIT con relativi messaggi "signoff reason".

Tecnicamente QUIT chiude la connessione TCP col server e chiude il client. Qualche volta a causa di una brutta connesione il QUIT non arriva al server o il messaggio(ack) dal server non raggiunge il client. In questi casi QUIT chiude semplicemente il client e noi non vediamo nessuna risposta dal server.
In ircII invece si usa il cmd DISCONNECT.

Di solito le diconnessioni sono involontarie (Ad ogni modo il client ci avvisa quasi sempre di cosa si tratta) e possono avere molte cause vediamone alcune:


•Collisione di nickname



•Operator Kill



•Server Downtime("Connection refused")
E' intuitivo


•Ping Timeout



•Connection Reset by Peer



•Excess Flood



•Kill Line Active



•Altri tipi di disconnessione

I canali --in qualche altro sistema di chat si chiamano pure rooms o MUCs(Multi User Chat in XMPP )-- rappresentano un importante fattore architetturale perché chi si connette anzichè vedere globalmente tutti gli utenti connessi alla rete e anzichè tutti i messaggi andare verso tutti può scegliere di unirsi(join) a uno o più canali di sua scelta e vedere e comunicare solo con chi ha fatto la stessa scelta.
Il channel è identificato dal nome che dovrebbe riflettere il topic di discussione o il tipo di persone che lo frequentano. Ad ogni modo Nome e soggetto sono arbitrari. Ognuno può creare un canale proprio nominarlo come vuole e parlare di qualsiasi cosa. L' unica eccezione a questa regola è per i canali in una rete che mette delle condizioni(policy) sul tipo di canali che l' utente può creare p.e. impedisce canali sul sesso.
Inoltre associato al canale c'è anche il topic che è una descrizione dell' argomento di discussione o degli eventi nel canale pur esso assolutamente non necessario

Teoricamente un canale può avere tutti quanti gli utenti che stanno sulla rete a cui il canale appartiene ma in realtà la sua dimensione è molto minore IMHO molto meglio cosi. Immagina di essere in un canale con parecchie migliaia di persone già con un migliaio di persone gestire i messaggi che arrivano è caotico.

• tipi di canali
Un canale può essere presente o globalmente su tutti i servers di una rete IRC o localmente su un solo server. I canali globalmente presenti su una rete sono contraddistinti dal nome preceduto dal simbolo "#" quelli invece presenti localmente su un solo server hanno il nome preceduto dal simbolo "&". In quest' ultimo caso non c'è collisione di nome(interferenza) se lo stesso nome si trova su servers differenti nella stessa rete IRC.

Per completezza esiste un terzo tipo di canale(del tipo globale fra tutti i servers di una rete) ormai è raro e in via di estinzione presente su servers con una certa mask tipo:è un canale disponibile a utenti che usano servers con mask "*.be" cioè Belgi. Per questi canali nel fare il join dobbiamo specificare anche la server mask:Condizione necessaria affinché un canale di tale tipo sia globalmente visibile su tutti i servers con mask "*.be" è che i servers siano connessi direttamente fra loro.

Un quarto tipo di canale ha un prefisso + e non è disponibile per tutti i tipi di servers ma solo per quelli della reti Undernet e IRCnet. Questo tipo di canale ha la caratteristica di disabilitare i cmds di gestione del canale. Questa è una feature molto vecchia che si è tentato di reintrodurre senza molto successo però. Attualmente il perchè dell ' esistenza di tali canali sta nel offrire un ambiente più libero senza politiche di gestione e utenti con privilegi come di solito accade per i canali globali.
Gli IRCnet servers già dal 2000 hanno immesso un altra forma di canale con prefisso "!" ma la loro funzione e propositi rimangono oscuri.

Ad ogni modo i canali globali(quelli con prefisso "#") sono la maggioranza e potenzialmente hanno molti più usi (e problemi). Abbiamo già detto che le diverse reti IRC sono scorrelate l' una dall' altra ossia non sono interconnesse quindi un canale su una rete può avere una controparte su un' altra di cui ha in comune solo il nome. Per esempio il canale #irchelp sulla rete IRC EFnet nulla ha a che fare col canale omologo ( #irchelp ) sulla rete IRC Undernet. Ognuno ha i suoi settings, le sue regole, i suoi utenti, i suoi operatori(ops). In alcuni casi capita che siano stesse le persone che mantengono canali con lo stesso nome su reti IRC diverse e tali canali sebbene sembrano simili devono essere acceduti con /join distinti, devono essere mantenuti separatamente, e certamente richiedono connessioni ai server separate.

Tutti i servers tengono la lista attuale dei canali in memoria e alcuni permettono di ottenere una grande parte(il server contiene anche canali segreti che non appaiono alla lista perchè i loro operatori li hanno impostati dicendo al server di non divulgare nessuna informazione riguardo i loro canali e utenti.) di essi attraverso ll cmd LIST. Dipende dal client utilizzato è possibile ordinare la lista o limitarla a un certo gruppo si canali con caratteristiche comuni.

Dipende dalla rete ma in genere fra il 30-60% dei canali delle reti sono segreti perciò mancano dalla lista dei canali. E' la differenza che si nota fra i canali che dà il cmd LIST e i canali che dà il cmd LUSERS. La sintassi base di LIST è:
Il numero che segue il nome del canale(se il nome del canale --incluso il simbolo #-- supera i 10 caratteri molti clients possono troncarlo. Si devono cambiare le impostazioni nel client per far a meno del troncamento) è il numero degli utenti attuali a cui segue il topic del canale
Molti clients permettono di limitare la lista di canali attraverso dei filtri che corrispondono a parametri del cmd LIST. Non tutti questi parametri sono comuni a tutti i clients ma un buon client supporta la maggior parte di essi:

Oltre che tramite il client i canali si possono ricercare (globalmente --non solo nella rete IRC o nel particolare server a cui siamo attiualmente collegati--) tramite un browser mediante motori di ricerca fatti apposta come per esempio /irc.netsplit.de/channels . Essi vanno a cercare la parola chiave --che immettiamo nel loro campo di ricerca-- fra ii topics dei canali di cui sono a conoscenza e ci riportano il nome del canale, la rete a cui appartiene, il topic del canale e eventualmente un link tipo irc:// che ci fa connettere(se abbiamo un client irc installato) al canale

• Disconnessione a causa di LIST



• Nomi di canali strambi



• lista di canali che non funziona



• ircII lista di canali che scorre verso l'alto e apparentemente non sono accessibili



• Trovare il giusto canale per noi

Il cilent manda un cmd JOIN al server e quest' ultimo controlla se il client ha i permessi per unirsi al canale scelto dal utente(ricordiamoci che "#" è parte del nome del canale e di per se da solo forma un nome di canale valido). Normalmente per un canale pubblico non si pone problema con i permessi:Quando il server accetta la connessione noi vedremo sullo schermo:

Nella prima linea(contraddistinta con *** invece + indica la continuazione nella linea successiva) si vede il nickname(harry_kar) e il canale scelto (#boinc-it)
Nella seconda linea viene riportato il topic
Nella teza invece viene riportato chi ha stillato il topic attuale(#boinc-it _Danilo_!~mdt@unaffiliated/danilo/x-728421) e quando(1266076810). Il tempo qui come in Internet si misura in epoch

Nella quarta riga(#boinc-it 1264779418) abbiamo il tempo di creazione del canale sempre in epoch

Otteniamo banned come risposta del al nostro cmd JOIN se la nostra user mask combaccia con un record della banned list del canale(ogni canale ha la propria lista di ban). Qualche client riporterà "unable to join channel (+b)" . Un "channel Op" imposta un ban mettendo +b (un "channel mode") per un certo nickname o host mask e permane finche l' OP non lo disattiva o non chiude il canale. Se si vuole essere sicuri si può guardare alla ban list prima di entrar nel canale:otterremmo un lista di host mask. Un ban può riguardare un intero dominio o tutto (*!*@*) come nel caso di un' aggressione e ban di tutti per un po.. Quando si è in ban meglio non insistere col ricollegarsi allo stesso canale potrebbe essere rinnovato il ban. Il ban è molto più probabile su canali di grandi reti IRC che su quelli di piccole reti. Più flessibile è il cambio indirizzo IP dell' utente più drastico diventa l' OP e più grande risulta il numero degli utenti(purtroppo anche quelli che non c'entrano niente) in ban. A volte vanno in ban interi ISP.

Uno dei modi per salvaguardare l' integrità del canale è proteggerlo tramite password. L' utente duarante il join deve fornire una password(keyword nel lingo IRC):Il server hanno già la password che la comparano con quella data dall' utente e decidono se impedire con "Bad channel key" o permettere il join

Un altro modo per gestire il canale è quello di limitare il numero dei suoi utenti. In tal caso il server compara il numero degli utenti attuali col limite prefissato e non permette il join di ulteriori utemti se il limite è stato già raggiunto.

A differenza dei canali più picoli i grandi canali spesso hanno una ban list informale. Uno o più clients(spesso robot clients) nel canale tengono ognuno la propria ban list indipendente dalla ban list del canale. Quando questo client-robot vede un utente indesiderato gli fa automaticamente(con una combinazione di +b e del cmd KICK) il ban e il kick(lo butta fuori) dal canale.
I ban di questo tipo durano poco(per risparmiare memoria nella ban list per far posto ai ban irregolari --che sempre possono capitare--). Ban e Kick sono 2 azioni distinte e noi in genere vedremmo sullo schermo 2 notifiche come:Le cause di Ban+KICK sono le stesse di un ban regolare.

Se il canale ha pochissimi utenti è probabile che essi pian piano se ne vadanoo facendoci rimanere alla fine soli. Un altra ragione potrebbe essere dovuta al netsplit(durante il tempo di ricezione- lettura della lista con il tentativo del nostro join al canale il nnostro server si è disconnesso dagli altri per cui la lista ce la fa vedere vuota). Questo inconveniente di solito si risolve in poco tempo. Comunque noi possiamo assicurarci che si tratta di netsplit e non di altro dando il cmd LUSERS. Se il numero totale di users +servers è molto minore di quanto dovrebbe essere o quando il nostro server dice di non essere connesso ad altri è il caso di un netslpit.

Questo messaggio si riferisce ai servers della rete IRCnet e tecnicamente è molto simile al problema di "nick delay". Questa condizione è conosciuta pure come Channel delay(CD) e occorre quando i canali perdono gli Ops e sono vuoti. P.e. l' ultimo Op è vittima di un KILL oppure un netsplit lascia tutti gli Ops da una parte e nessuno Op dalla nostra parte. Il canale si riaprirà quando il nesplit verrà riparato e ritorneranno gli Ops che verranno cisti anche dal nostro server. Se gli Ops non ritornello entro un certo periodo di tempo(minimum 15 minuti) il CD finisce e il canale apre di nuovo comunque sia. Ogni server implementa il CD individualmente non c'è una regola comune

Un canale invite-only è configurato in modo da permettere il join solo da utenti che hanno ricevuto un invito da un "chan Op". Si vedrà una notifica tipo:Il server controlla se c'è un invito per noi per fare il join al canale e ci impedisce il join se non c'è nessun invito. L' invito dura finché siamo collegati col server. Se per qualche motivo ci disconettiamo abbiamo bisogno di un nuovo invito per ricollegarci al canale.
Di solito gli utenti di un canale invite-only tengono alla loro privacy e spesso lo impostano anche come segret. Ottenere un invito (specialmente se non ci si è stati mai prima) in un canale invite-only è impresa ardua. Si potrebbe tentare di contattare un "chan Op" ma la situazione è analoga a quella di bussare a una porta sapendo che i proprietari hanno già dichiarato che le visite sono sgradite.

Una volta fatto il join su un canale se vogliamo vedere chi altro ne fa parte ad un certo istante diamo:oppure se il client lo permette:Per ottenere maggiori informazioni si può dare il cmd WHO:
il primo campo è il nome del canale, il secondo è il nickname, il quarto è l' indirizzo, il quinto(dentro parentesi) è il Realname o ircname (in qualche rete è preceduto da un numero che indica i server hops: il numero di nodi fra noi e l' utente sotto esame. Per il client che esegue WHO questo valore è sempre 0) e il terzo è il "user status" (per come lo vede il server) che può essere "G" o "H" :

Il carattere che precede il "user status" può essere *, +, @

dipende dal server ci possono essere altri caratteri:

Questo fenomeno(non è direttamente relazionato con i canali) influenza tutta una intera rete IRC e quindi i suoi canali ed risulta da problemi di connettività del server o interventi di un operatore sul routing del network.
Gli utenti di un canale possono capire l' evento di un netsplit dai messaggi quit emessi che sono caratteristici. Se vediamo 2 o più utenti che fanno sign off con nomi di 2 servers come messaggio quit significa che questi 2 utenti stanno dall'altra parte di un server link che è appena guastato. Nelle reti IRCnet il "quit reason" invece contiene il server splitted dalla nostra parte e il server dell' user di cui si è fatto il sign off. Tutti gli altri tipi di server indicano il link guastato.
Un netsplit si ha quando per qualche ragione si perde il collegamento fra 2 servers. Quando si ha un netsplit quindi un server o un gruppo di server perde contatto col resto di servers e ambedue le parti funzionano come se fossero reti separate. Ogni parte vede i server(e relativi clients ad essi connessi) dell' altra parte come sconnessi.

Lag e netsplits spesso vanno di pari passo. Uno può causare l'altro e può portare a un circolo vizioso che a sua volta può creare un grande caos su grandi reti IRC se coinvolge molti dei suoi servers centrali. Un grande carico su un server porta a un rallentamento di elaborazione del traffico di rete e può causare lag. Comunque spesso il lag è dovuto a qualche problema di rete che rallenta il traffico server-server. Come risultato il server da una o dall' altra partedi un link del genere comincia a mettere in coda(mettendo tutti i nuovi messaggi alla fine della coda) dei dati destinati verso l' altra parte. Ciò porta ad una trasmissione ritardata.
Se ciò capita ad un hub server centrale che ha tanto traffico in ingresso e uscita gli effetti sulla communicazione nella rete saranno più che visibili. Se l' ammontare dei dati accodati (per una singola destinazione) nel server supera un limite massimo (prestabilito nel file di configurazione nel server) il server chiude il link verso l' altro server portando a un netsplit. Quando il link viene restaurato tutte le connessioni di clients e servers che da una parte o dall' altra sembravano chiuse sono ritrasmesse insieme ai "channels mode" e "users mode". Tutto ciò è un gran bel ammontare di dati che se il server destinazione non riceve e processa sufficientemente velocemente vengono accodati per cui inizia un nuovo ciclo di lag e potenziali netsplits. Se la riconnessione automatica dei servers fallisce nel creare un nuovo insieme di lins funzionanti gli "IRC ops" devono intervenire e piazzare i serrver che provocano lag in un punto meno centrale della rete rimpiazzandoli con server alternativi come hubs principali.

Questo è un altro tipo di delay(ritardo) nella trasmissione di messaggi. Si può rilevare tale lag usando il cmd /PING ( CTCP ) .Se si rileva un alto tempo il problema può essere indifferentemente o il link fra client e server o un server o client con alto carico(load).
Dopo un netjoin i servers non rimandano molte informazioni per ridurre l' ammontare di dati trasferiti durante il sync. Molti tipi di servers non rimanderanno il user status(away ecc) e il topic del canale. Cosi l' utente dovrebbe reimpostarli per poter essere di nuovo visibili attraverso la rete. Mentre l' utente non potrebbe mai accorgersi che il proprio userstatus non viene propagato potrebbe invece osservare che menre lui non vede il topic del canale altri utenti sullo stesso canale lo vedono o viceversa

By Alexander Charalabidis
No Starch Press 2000
ISBN: 1-886411-29-8

By Paul Mutton
O'Reilly 2004
ISBN: 0-596-00687-X
online