martedì 17 settembre - 16:25
Google
 
Menù
  Home
  Come nasce IRC-Zone
  Glossario Informatico
  News
  I nostri progetti
  I nostri servizi
  Partners
  Diventa un Partner

IRC
  Cos'è IRC
  Storia di IRC
  Netiquette su IRC
  Emoticons
  Gergo della chat
  Lista Servers
  RFC 1459
  Shell Hosting

mIRC
  Cos'è il mIRC
  FAQ mIRC
  Configurazione mIRC
  Download mIRC
  Novità
  Script Stranieri
  Script Italiani
  MTS
  MTS Engine

mIRC Addon
  mIRC addon Audio
  mIRC addon SMS
  mIRC addon Grafica
  mIRC addon Utility
  mIRC addon Uso Bot

Client IRC
  Client IRC Linux
  Client IRC Mac
  Client IRC Win

XChat
  Cos'è XChat
  XChat per Win
  XChat per Unix

KVirc
  Cos'è KVirc
  FAQ KVirc
  Installazione su Linux
  KVirc Scripting
  KVirc per Mac
  KVirc per Win
  KVirc per Unix
  KVirc addon

Irssi
  Cos'è Irssi
  Download Irssi
  Download Moduli

Eggdrop/Windrop
  Cos'è un Eggdrop
  Download Eggdrop
  Configurazione Eggdrop
  Download Windrop
  Installazione Windrop

Tcl
  Download TCL
  Tutorial TCL scripting
  Documenti/Guide

BNC
  Cos'è un psyBNC
  Download psyBNC
  Configurazione psyBNC
  Download sBNC
  Configurazione sBNC

Linkaci!
footer

Credits
Somerights

footer

Statistiche
Ip: 18.204.2.53
Download: 1079778 file
Totale: 1653259 MB

footer

Links amici



IRC Services; Pro e contro

Autore: PUOJACKZData: 2005-11-09
Modificato: 2005-11-12 Letture: 4892
Torna indietroStampa articoloInvia ad un amico

1. Introduzione

Oggigiorno, esistono molte reti IRC al mondo, che seguono varie politiche di gestione ed amministrazione. Alcune seguono di più il protocollo IRC (RFC 1459), rispettando il più possibile tali regole, mentre altre han introdotto delle innovazioni. La più chiara tra queste modifiche è la presenza del NetWork Service.

2. Sì, ma creare un IRCd che non rispetta il protocollo, può comportare dei problemi?E riguardo l'RFC?

Beh, prima di tutto, iniziamo spiegando una cosa: il protocollo IRC non è un regolamento al cui non ci si può sottrarre, o si rischia la pena capitale. No, assolutamente. E' solo una serie di regole "pubbliche". Ovviamente, se le si segue, tutti i dispositivi e i programmi creati basandosi su questa serie d'idee, saran compatibili. Se si decide di far di testa propria, magari creando un nuovo protocollo, proprio, occorrerà anche tener in considerazione che, probabilmente, i clients IRC più conosciuti non riusciranno a connettersi o a formattare il testo o i comandi in modo corretto.
Tutto ciò potrebbe avere un effetto negativo sulla popolarità della rete.
Ad esempio, se quando effettuo il comando /JOIN #Canale, su una rete IRC che supporta un IRCd particolare, al posto di entrare nel canale specificato, ci ESCO (e viceversa), il caos che si verrà a creare sarà un deterrente decisivo, e, sicuramente, tutti gli utenti che utilizzano degli scripts o dei programmi, ove il comando JOIN è impiegato per entrare nel canale, avranno dei problemi a chattare in tale rete.
Occorre, però, non lasciarsi spaventare dalle nuove implementazioni non regolamentari.
Ad esempio, DALnet ha portato la lunghezza dei nicknames, da 9 caratteri, a 30. Questo non ha pregiudicato minimamente il funzionamento dei clients, ed, infatti, anche se non è stato rispettato lo standard, i clients più famosi non han avuto problemi di compatibilità.

2.1 Scusa, ma vi sarà un motivo chiaro e plausibile del perchè alcune reti han deciso di non seguire il protocollo?

Qui s'inizia ad addentrarsi nella politica di amministrazione delle reti IRC.
Ad esempio, il ban globale. Undernet ha deciso per la G:Line, mentre DALnet ha introdotto l'Akill. Chiunque, ora, potrebbe chiedersi "Perchè?", infatti, alla fin fine, hanno lo stesso effetto, cioè bannano un utente da tutta la rete.
Su questo particolare non vi son dubbi, ma la G:Line dev'essere impostata da almeno 3 IRCOp della rete ed è a durata SEMPRE temporanea (es. anche 2 anni di durata, ma è temporanea). L'AKill, invece, viene settata dai servizi e può allontanare un host/IP/Sito/Regione permanentemente. La differenza è stata decisa dall'amministrazione.
Evidentemente, sia per Undernet che per DALnet, occorreva ideare un sistema per allontanare, da tutti i server della rete, un host sorgente di abusi. Su IRCNet, ad esempio, nell'IRCd 2.10 (senza patch), di alcuni anni fà, non vi era il ban globale. Ultimamente han introdotto la Global Kline, che è un'altra versione di ban. Produce lo stesso effetto della G:line e AKill, ma cambiano alcune particolarità. IRCNet, ad esempio, ha preferito utilizzare comunque la K:Line per mantener fuori un host, piuttosto che aggiungere una stringa a tale scopo.
Per concludere, l'importanza dell'aggiunta di un opzione o di una feature, non è detto che venga condiviso da tutte le reti IRC esistenti. Ogniuna decide autonomamente.

2.2 Ok, ma le implementazioni apportate da UnderNet, DALnet ecc... han avuto un importanza fondamentale?

Beh, DALnet introdusse le U:Line, in modo da garantire la possibilità, ai services, di modificare la rete senza che le routine di resynch annullassero gli effetti.
Ovviamente, anche in questo caso, l'importanza delle modifiche è strettamente legata alle idee dell'amministrazione (le quali potrebbero non essere condivise da tutti).

3. I Pro & I Contro dei services

Qui di seguito verran descritti i pro e i contro generici nell'avere i services nella propria rete IRC.

3.1 Perchè avere i services?

- Vi son 2 problemi nelle reti IRC, le collisioni e i TakeOvers. Grazie al ChanServ e al NickServ, un utente può essere sicuro che la propria identità e la propria stanza siano sempre, a lui disponibili, senza dover partecipare a guerre di canale, che spesso conducono a DoS non solo degli utenti, ma anche dei servers, trasformando la rete IRC in un campo di battaglia.

- Rende totalmente inutile lo sfruttare gli splits (il più delle volte indotti), per ottenere lo status di ChanOp in un canale, in quanto, i services, durante la fase di NetHealing, ripristinano le modalità originarie del canale, deoppando chi non è presente nelle liste ufficiali.

- Evita che il canale sia insediato da centinaia di bots, per il mantenimento dello status di moderazione. Inoltre, la mancanza della botnet evita che i chanop finiscano vittima delle misconfigurazioni contro il flood di canale.

- Permette la conservazione delle identità/canali, aggiungendo a queste ulteriori opzioni di gestione, oltre ad informazioni riguardo il suo possessore. Nelle reti senza services, per inserire alcuni dati del canale (es. se è di una community), occorre occupare lo spazio del Topic, che, secondo l'RFC è destinato per descrivere l'argomento di discussione.

- Garatisce l'uso del chan/nick a chi lo ha registrato, anche se un utente estraneo lo stà momentaneamente impegnando, richiedendo la liberazione forzata. Questo evita che un harraser possa utilizzare il nickname per screditare il vero possessore. Inoltre, non richiede il collegamento di bots che conservino il nickname, durante i periodi di assenza del suo utilizzatore ufficiale. Nelle reti senza Services, un utente può non solo usurpare l'identità di un utente, per causare problemi, ma anche spacciarsi per IRCOp.

- E' possibile collegarlo alle liste di canale del ChanServ, in modo che solo l'utente originale può ottenere gli status nei canali ove ha accesso. Questo evita i TakeOvers. Nelle reti senza Services, una volta che il canale ha perso tutti i suoi operatori, non è più possibile riprendere lo status di moderatore, lasciando il canale in completa balia dei flooders.

- Fornisce, a volte, degli strumenti per rilasciare delle note o dei memo, agli utenti registrati. Questa opzione è molto utile per avvertire gli utenti non correntemente online, riguardo un qualsiasi evento, senza attendere che questo ritorni attivo.

3.2 Perchè non avere i services?

- Ogni rete è indipendente e differente. Se tutte quante avessero le stesse opzioni e feautres, non avrebbe senso l'essere divise.

- Per evitare i TakeOvers, alcune reti implementano l'HalfOp, pertanto, il rischio di perdita di controllo del canale si riduce.

- Alcune reti, come EfNet ed IRCnet, hanno già pensato se fosse opportuno implementare dei servizi di registrazione. Purtroppo, però, non è detto che tutti sarebbero d'accordo con tale idea. Inoltre, sarebbe ancora più duro, successivamente, stabilire di chi è un canale o un nickname. Ad esempio, se il servizio viene attivato il giorno in cui tu non ci sei e qualcuno registra il tuo nickname, tu non lo puoi più usare. Stesso discorso per i canali.

- La registrazione toglie la possibilità di libertà. I canali vengono registrati, e così i nicknames, pertanto, non vi è più la regola del "Chi prima arriva meglio alloggia". Inoltre, gli IRCOps possono modificare arbitrariamente i dati delle identità, dando o togliendo la possessione dei canali/nicks. Nelle reti senza registrazione, gli operatori, simili privilegi, non ne hanno e quindi non l'utente è libero di aprire tutti i canali che vuole e svolgendo qualsiasi attività desideri.
 
- La registrazione diminuisce la responsabilità in canale, pertanto, gli operatori possono anche gestire la chat in modo errato. Qualora questa venga resa inutilizzabile, il ChanServ ripristina le modalità come se nulla fosse accaduto. In una rete senza services, quando sbagli a fornire uno status e il canale cade in TakeOver, chi ha mancato d'attenzione impara la lezione ed evita di ricommettere lo stesso sbaglio in futuro.

- Gli IRCOps/Admins possono ottenere status di canale, senza che sia un moderatore a fornirglieli. Nelle reti IRC ove OperServ non è presente, gli IRCOps non possono ottenere la modalità ChanOp, se non è un operatore di canale ad offrirgliela.

- L'uso dei canali, a volte, è impossibilitato senza un valido motivo (es. senza che vi siano bans all'interno o flags), da parte dei Services, in quanto, gli IRCOps han bloccato l'uso di questo. Nelle reti IRC senza services, nessuno può bloccare l'uso di un canale, se non carica, a suo interno, dei bots, con status moderatore.




 

Branzilla Contest Redeem

Links utili

Newsletter
Iscriviti
Cancellati

Ci sono 42 iscritti

In rilievo..
  JackSMS v3
  Venom Script Lite

Documenti/Guide
  I Social Network
  Sicurezza in rete
  Cos'è SSL
  FAQ Bot
  Documenti su IRC
  FAQ Ident
  RFC 2810
  RFC 2811
  IRCx RFC

Informatica libera
  Gli Hoaxes
  Hoaxes report
  Documenti vari
  CensorWare
  Windows
  Linux

mIRC Scripting
  Codice ASCII
  Snippet mIRC scripting
  Tutorial mIRC scripting
  Dll per mIRC
  Utilities

IRCd
  Cos'è un IRCd
  Download Unreal
  Download Hybrid 6
  Download Hybrid 7
  Download Ultimate
  Download Bahamut
  Configurazione IRCd

IRC Services
  Cosa sono i Services
  Download Anope
  Download Epona
  Ircservices 5.0
  Ircservices 5.1
  Configurazione Epona
  Configurazione Anope
  Comandi ChanServ
  Comandi NickServ
  Comandi MemoServ

NeoStats
  Cosa sono i NeoStats
  Download NeoStats
  Configurazione NeoStats
  Download Moduli

IPv6
  Cos'è IPv6
  IPv6 su Win2000
  IPv6 su WinXP
  IPv6 su Linux
  IPv6 su mIRC e Xchat

Programmazione
  Tutorial C++
  Tutorial C
  Compilatori C/C++

Altro
  Contatti
  Banners Gallery

RSS Feed




Progetti
Starlight
IRCHippo

Validato CSS
Sito interamente sviluppato in PHP
MySQL
©2004+ IRC-Zone | Webmaster | Sitemap
Created by Cesare 'Kaesar83' Lasorella
Designed by Manuel 'erkokki' Cabras
IRC-Zone non è responsabile del contenuto dei siti linkati
Pagina creata in: 0.029 sec con 27 queries
Spampoison
Sviluppato con Notepad++
website monitoring service