Ancora prima di cominciare a scrivere codice è necessario comprendere come la struttura di USENET si articola e con quale tipo di applicazione server (daemon) si andrà a colloquiare utilizzando gli strumenti messi a disposizione da Visual Basic.
Per consentire una gestione attenta e metodica del traffico USENET sono necessari delle applicazioni o pacchetti di software che compiono differenti operazioni: dalla lettura degli articoli in arrivo all'assegnazione di un ID univoco a ciascuno di essi, alla registrazione delle attività di entrata e uscita dei dati, alla comunicazione e condivisione dei dati con i server collegati in rete.
Fin dall'inizio lo sviluppo di USENET ha infatti continuato ad adattarsi seguendo come riferimento i modelli di evoluzione dei software ad esso correlato.
I maggiori pacchetti di software attualmente disponibili sono tre: B2.11, Cnews ed InterNetNews. Tutti e tre, pur essendo strutturati diversamente sotto alcuni punti di vista, mantengono un'impostazione di base molto simile: un qualsiasi newsgroup come può essere comp.foo viene mappato in locale all'interno di una directory denominata comp/foo.
Qualsiasi articolo inviato a questo newsgroup riceve in tal modo un numero intero progressivo (una sorta di contatore) che lo identifica univocamente e la coppia ID-articolo viene registrata in un file di log chiamato active file.
Nel caso in cui il medesimo articolo venga inviato a più gruppi contemporaneamente, viene attivata una serie di collegamenti e segnaposto in modo tale da mantenere un'unica copia dei dati.

NOTA: Si può accostare questo procedimento alla creazione di collegamenti di file nei sistemi Windows: il collegamento al desktop di un qualsiasi file infatti non corrisponde al file originale. Attivando però questo link si arriverà ad avviare il file di origine.

Un secondo file di estensione .sys elenca poi al suo interno tutti i nomi estesi dei newsgroup che il server ha scelto di ospitare.

Nei seguenti paragrafi si analizzerà ciascuno di questi pacchetti di software per studiarne i vantaggi e i difetti.

Il modello BNews, conosciuto anche come B2.11 rappresenta probabilmente il pacchetto software meno indicato a compiere le migliaia di operazioni complesse che devono essere gestite giornalmente da un server delle news.
La singola applicazione che corrisponde al nucleo del pacchetto è denominata rnews ed il suo compito principale è quello di monitorare gli articoli in arrivo. In tale processo è necessario mantenere però un sistema di bloccaggio delle istanze di rnews per permettere di esaminare un messaggio alla volta ed evitare così che più processi rnews tentino di modificare contemporaneamente il l'active file.
In caso contrario infatti, un'articolo inviato contemporaneamente verso più newsgroup otterrebbe la doppia indicizzazione nel file di log.
Per evitare duplicazioni ciascun articolo processato da rnews infatti viene confrontato con l'history database ossia l'archivio di tutti i movimenti in entrata ed in uscita dei dati: se risultava già esistente l'articolo veniva pertanto scartato.
In ogni caso il bloccaggio (locking) degli articoli in arrivo risulta talvolta inefficiente a causa delle proporzioni del flusso di messaggi (si parla di circa 15.000 al giorno).
Se ciò si dovesse verificare come saltuariamente accade, ci saranno alcuni duplicati che però sono contenuti tra i 10 e i 100 al giorno.
Il collo di bottiglia che rende però sistema BNews di fatto privo di qualsiasi utilità nella maggior parte dei casi è rappresentato dai processi di lettura e scrittura da e verso i file: solamente il trasferimento di articoli verso gli altri server connessi in rete porta il conto di accesso ai file a raggiungere un totale di circa 150.000 operazioni.

A differenza del precedente, il pacchetto Cnews consente sicuramente delle prestazioni più evolute, il che significa poter gestire correttamente il flusso di articoli senza incorrere in errori o duplicazioni.
L'applicazione su cui si basa il modello è denominata relaynews ma contrariamente al sistema su cui è basata rnews viene avviata ed interrotta più volte al giorno ad intervalli regolari di tempo o ancro meglio di messaggi in arrivo. In questo modo relaynews processa solamente i dati ricevuti dall'ultimo avvio in poi.
Questo aspetto rappresenta una sicura miglioria rispetto al modello presentato da BNews: prima di tutto, non essendo sempre presente, l'applicazione evita di appesantire la fase di arrivo di articoli. In secondo luogo evita di dover ricorrere al locking del file active.
La ragione per cui si è pensato di passare al relaynews risiede fondamentalmente nell'indiscutibile convinzione che processare un articolo alla volta richiede delle risorse eccessive e che è molto più semplice accodare i messaggi in un batch ed inviarli sottoforma di unici pacchetti al software incaricato a gestirli.
Un ulteriore metodo per evitare duplicazioni consiste nell'installazione di una seconda applicazione presente nel pacchetto denominata msgidd, ossia un daemon che mantiene in memoria il lungo elenco degli interi che identificano ciascun articolo ricevuto nell'arco delle ventiquattr'ore.
E' pertanto sufficiente un'analisi degli ID in memoria per determinare se il nuovo articolo processato è utile oppure deve essere scartato.
Anche questa soluzione però presenta degli svantaggi non indifferenti: si parla in questo caso non più di duplicazione ma, ancor peggio, di perdita di dati.

Si è già detto che tutti gli articoli vengono accodati e compattati. Questo processo però non è privo di intoppi: alcuni dati possono risultarne danneggiati oppure vengono perduti. In tal caso l'applicazione msgidd, impossibilitata a rilevare lo stato di integrità dei dati che le vengono passati, memorizzerà in ogni caso anche l'ID dell'articolo andato perso oppure danneggiato ed in ogni caso illeggibile ed irrecuperabile.

Dalle conclusioni alle quali si giunge comparando i modelli BNews e CNews risulta comprensibile la necessità dell'implementazione di un nuovo sistema di gestione del sistema USENET: si giunge così ad InterNetNews.
InterNetNews, creato originariamente da Rich Salz ed in seguito preso in gestione dal ISC, l'Internet Software Consortium che col passare degli anni ne sta ampliando le caratteristiche in base ai requisiti di USENET è un pacchetto completo per la gestione e il trasporto degli articoli.
Lo sviluppo di INN pare essere davvero rapido, ragione per cui la proprietà e tutti i diritti relativi sono stati ceduti al consorzio ISC, e questo fattore è confermato dalla sempre maggiore richiesta di beta tester e di consulenti che si ritrovano per riorganizzare e scambiarsi le informazioni in proprio possesso utilizzando la mailing list a cui si può accedere liberamente tramite l'indirizzo:

inn-workers-request@isc.org

InterNetNews può essere scaricato liberamente all'indirizzo ftp://ftp.isc.org/isc/inn/ dove si trovano le maggiori versioni del software. Al medesimo indirizzo è poi possibile trovare tutta la documentazione relativa al suo utilizzo (in special modo documentazione legata alle questioni di sicurezza, i cosiddetti "buchi" di cui questo software come tutti non è immune).
Nonostante InterNetNews sia stato progettato fondamentalmente per UNIX, è poi stato studiato un ambiente del tutto simile a UNIX ma adattato a Windows di nome Cygwin. Per maggiori informazioni visitare il sito:

http://members.verizon.net/~vze4y7p6/inn/

news.software.nntp: tratta in modo generico di tutte le applicazioni server in qualche modo legate al protocollo NNTP e quindi anche di innd. E' sicuramente il gruppo più adatto a risolvere questioni più puramente tecniche;
news.software.b: è simile al precedente ma attualmente sembra aver terminato l'attività;
news.admin.technical e news.admin.misc: rappresentano due newsgroup utili per domande tecniche riguardo l'amministrazione delle news.
news.admin.net-abuse: copre temi quali casi di abuso e prevenzioni dello stesso.

Unitamente ai canali sopra elencati esistono delle mailing-list create intorno al tema innd e NNTP:

inn-announce@isc.org: permette di rimanere informati sulle novità di innd: nuove release, rilascio di documentazione tecnica aggiornata e così via.
inn-workers@isc.org: contiene discussioni relative il livello di sviluppo dell'applicazione.
inn-bugs@isc.org: permette di riportare bug rilevati all'interno di innd.

Nelle sezioni che seguiranno verranno trattate brevemente queste applicazioni, distinguendone l'ambiente di applicazione e le differenti peculiarità.