Ottavo Articolo
Parte 8
TCP/IP
Protocolli ed altri Misteri
E' ormai un anno che ho iniziato a scrivere questa serie di
articoli sul TCP/IP e sugli altri argomenti riguardanti il
Packet Radio e le trasmissioni digitali in genere.
Nell'accingermi a questa fatica letteraria speravo che i miei
scritti destassero una gran quantita' di commenti e richieste di
chiarimenti soprattutto dai cosiddetti "SYSOP". I System
Operators, infatti, sarebbero quelle persone che, piu' dotate di
conoscenze specifiche e di desiderio di fare e capire, sono
impegnate nell'identificazione delle strutture della rete
(progetto), nell'installazione e nella gestione della stessa al
fine di rendere un servizio alla collettivita' divertendosi e
passando piacevolmente il tempo.
I concetti generali che ho espresso in piu' riprese avrebbero
dovuto essere, nella mia intenzione, la guida per ben valutare
le scelte di progetto della rete nel suo insieme e dei singoli
componenti in particolare (nodi, BBS, radio, antenne ecc.).
La realta' e' stata abbastanza diversa: a parte pochissime
eccezioni, il mio e' stato essenzialmente un monologo.
Discutendo in varie riunioni ho avuto la certezza che la quasi
totalita' dei Sysop ignora i concetti fondamentali del Packet
Radio e le problematiche di rete. Sembra impossibile, ma c'e'
ancora chi ignora il problema del "nodo nascosto" e,
(incredibile !), lo confonde coi nodi Netrom il cui nome e'
nascosto se preceduto dal segno #. Evidentemente i Sysop o
erano troppo impegnati ad accapigliarsi sulle questioni di
forwarding fra BBS e nelle varie scaramucce locali fra fazioni
da non avere il tempo di leggere Radio Rivista, o i concetti
sono stati espressi in maniera troppo dispersa ed inefficace.
Per rimediare, nel caso sia vera la seconda ipotesi, vado a
riassumere i concetti principali che, da soli, hanno un notevole
impatto sul modo in cui la rete viene pensata e realizzata.
RIASSUNTO DELLE PUNTATE PRECEDENTI
Innanzitutto vorrei che fosse chiaro a tutti che il TCP/IP non
e' una cosa diversa dal Packet Radio: il tcp/ip e' il prototipo
funzionante di rete dati a commutazione di pacchetto e degli
applicativi che su essa si basano.
Il sistema e' certamente piu' complesso della singola
connessione punto-punto fra due stazioni dotate di TNC per il
semplice motivo che il tcp/ip implementa una rete complessa e
geograficamente distribuita basata su reti fisiche eterogenee ed
include gli applicativi (FTP, Telnet, SMTP ecc. che discutero'
in seguito) che sono lo scopo finale di tutta questa struttura.
Chi considera che il Packet Radio sia coincidente con i BBS
commette un grosso errore di valutazione: infatti i BBS non sono
altro che uno dei possibili applicativi che, per funzionare,
hanno bisogno di una struttura di trasporto dati basata sui
diversi livelli o strati logici e funzionali.
I gestori di BBS che non considerano l'importanza della rete e
delle funzioni di trasporto associate sono destinati a passare
la loro vita in interminabili discussioni ( e litigi) sul come e
con chi fare forwarding... e gia' alcuni stanno avviandosi alle
case di cura per malattie mentali.
La soluzione a questi problemi, che ormai da anni avvelenano
l'ambiente del Packet, consiste nell'affidare l'invio dei
bollettini da un BBS all'altro, impacchettati in file compressi,
ad una rete funzionante. Sara' poi la rete, con le sue tecniche
e modalita', a decidere i cammini ed i tempi in funzione delle
priorita' e del traffico.
Affiche' cio' si realizzi, (anche per la salvaguardia della
salute mentale dei Sysop) occorre realizzare una rete ben fatta
sul territorio nazionale capace di sopportare il traffico
richiesto....e qui' iniziano le difficolta': questo obbiettivo
e' difficile da raggiungere anche conoscendo bene le
problematiche. Se, poi, si confida solo nella propria
improvvisazione allora il risultato finale non sara' mai
raggiunto.
La difficolta' maggiore consiste nel fatto che non abbiamo la
pappa pronta...cioe' non esiste un modo semplice, con gli
strumenti che abbiamo, per realizzare una rete a copertura
nazionale e poi mondiale. Gia' dalla prima puntata abbiamo
visto che le reti NETROM non sono adatte per crescere oltre una
struttura di 10 o 15 nodi !... Quanti hanno meditato su questo
aspetto ? Che deduzioni se ne possono trarre ?
La prima deduzione e' che si debbono sperimentare altri tipi di
rete: la ROSE non e' che un esempio, ed altri ne stanno nascendo
in giro per il mondo come la FlexNet tedesca, la TexNet
Americana ecc.
La seconda e' che che siamo per i momento costretti ad
implemetare una rete gerarchica a due livelli. L'IP e' l'unico
software disponibile per una tale struttura capace di far da
colla fra piu' sottoreti fisiche fra loro isolate. (Si veda la
figura 2.1 R.R 4/90 pp32). Mi sarebbe piaciuto sentire un po'
di discussioni su questo argomento che, a mio parere, e'
fondamentale per gli sviluppi futuri.
Abbiamo inoltre visto che le NETROM non hanno affatto affrontato
il problema dell'indirizzamento: non esiste un "piano di
numerazione" capace di individuare un "attacco d'utente". Al
contrario l'IP ci risolve, seppur con le sue limitazioni, questo
difficile argomento. Notate che anche i BBS si dibattono ancora
sul problema dell'indirizzamento con interminabili discussioni
sui nomi gerarchici. L'utilizzo degli indirizzi IP risolverebbe
in un colpo solo queste questioni di per se delicate.
Da quanto detto si deduce che una delle azioni piu' urgenti da
svolgere in Italia e' quella di individuare e realizzare le
"sottoreti" ponendo ordine nella miriade di nodi nati a casaccio
e senza alcun piano di sviluppo secondo lo slogan "Ad ogni
campanile il suo nodo !". In questa fase i BBS possono
benissimo svolgere anche la funzione di gateway fra differenti
sottoreti.
Un altro problema di pari complessita' e' quello del livello 2:
il vero e proprio AX.25. Ho utilizzato ben due articoli della
serie sull'argomento per mettere in risalto i problemi di fondo
ad esso connesso e le possibili soluzioni. I nodi in altura, se
si vuole che funzionino decentemente, assolutamente devono
essere esenti dal problema del "nodo nascosto" altrimenti lo
sfruttamento del canale radio cade ben al di sotto del 18%
massimo teorico. !!!! Aspettando che siano disponibili
software che usino la tecnica del polling per l'accesso al
canale ( forza Genova !) non rimane che organizzare i nodi con
almeno 2 o piu' TNC e con tratte dedicate, meglio se
Full-Duplex, fra i nodi in altura e quelli in basso. L'utenza,
in questi casi, accede solo ed esclusivamente al nodo in bassa
quota posto in posizione tale da essere partecipe di una LAN (=
tutti si ascoltano fra di loro e tutti ascoltano il nodo).
Un altro aspetto che tutti dovrebbero stamparsi nella mente e'
che "non si puo' cavare il sangue dalle rape !" ovvero che da un
canale radio, diciamo a 1200 baud, non si possono far passare
quantita' di dati superiori alla capacita' del canale stesso.
E' perfettamente inutile mettere sulla stessa frequenza tante
stazioni, nodi o BBS la cui necessita' di traffico totale e'
superiore a quella del canale. Dite che e' un concetto
difficile ?... eppure quanti ancora si accaniscono ad
aggiungere nodi su nodi o BBS su BBS sulla stessa frequenza !
Finche' in packet si faceva solo conversazione Keyboard to
Keyboard la quantita' di traffico generata da ogni stazione era
di gran lunga inferiore alla capacita' totale del canale e
quindi sulla stessa frequenza potevano tranquillamente essere
attive molte stazioni. Ora che, al contrario, la gran quantita'
del traffico consiste in trasferimenti di grosse moli di dati
generati dai BBS o da file transfer, l'idea dell'utilizzo di un
canale comune a piu' servizi decade...a meno di poter usare TNC
velocissi, modulazioni speciali e, soprattutto radio speciali
costruite appositamente per il packet (AGC e commutazione R/T
velocissimi).
Da tutte queste argomentazioni si deduce che per fare una rete
funzionante occorre che tutti gli addetti raggiungano un comune
livello di comprensione sull'argomento e, soprattutto, che le
installazioni di nodi e BBS, nonche' la scelta delle frequenze,
dei modi di emissione e dele velocita' siano concertate ed
approvate dai vari coordinamenti regionali nell'ottica
dell'obbiettivo finale. ( tradotto significa: "Senza
collaborazione e coordinamento non si fa un tubo").
GLI APPLICATIVI
Ed eccoci a parlare dello scopo finale del TCP/IP e della RETE
in generale ! : gli "applicativi".
E' solo per i servizi che gli applicativi danno che vale la
pena di costruire una rete ben fatta ed efficiente.
Di applicativi ne esistono alcuni di uso molto comune presenti
in tulle le installazioni tcp/ip, altri sono meno noti od ancora
in fase sperimentale. Tutti gli applicativi, comunque, poggiano
al disopra del livello di trasporto TCP. (Fig. 2.3 R.R 5/90 p.
33). Nella struttura OSI gli applicativi sono al settimo
livello (R.R. 6/90).
TELNET
Il Telnet e' l'applicativo che permette ad un utente umano,
seduto davanti ad un terminale, di accedere ai servizzi del
sistema operativo di un computer remoto (Remote Login): (Fig
8.1). Quando si e' connessi ad un computer remoto si possono
dare su questo tutti i comandi come se si fosse fisicamente
collegati ad esso: si puo' quindi lanciare un applicativo o dare
un qualunque altro comando fra quelli riconosciuti dal sistema
operativo.
Nel nostro uso amatoriale, pero', non abbiamo computer multiuser
capaci di fornire contemporaneamente servizi a piu' utenti:
abbiamo al massimo dei PC che sono tipicamente monoutente,
quindi per noi il Telnet e' stato usato come applicativo
Keyboard-to-Keyboard. Il Telnet e' quindi l'applicativo per
usare la rete come la buona vecchia RTTY per scambiare due
chiacchiere in modo immediato fra due OM.
L'uso e' semplicissimo : al prompt del programma NET basta dare
il comando:
> telnet ik1che
per esempio. A questo punto la funzione telnet del nostro
programma si connette attraverso la rete con l'omologa funzione
del computer remoto. Se richiesto occorre dare l'USER e poi la
PASSWORD dopo di che' si e' in contatto diretto con l'OM
dall'altra parte. Dopo aver conversato via tastiera la
connessione si chiude ritornando in modo comando e dando:
> close 1
dove, nell'esempio, 1 e' il numero associato alla sessione. Una
cosa molto bella del programma NET e' che si possono avere
contemporaneamente tante sessioni aperte con altrettanti utenti
della rete sia di tipo telnet che altro.
I numeri associati alle varie sessioni si ottengono col comando:
> session
L'operazione di "loggin" consiste proprio nel dare il nome
dell'USER e quindi la parola chiave che abilita tale user.
Questo e' un retaggio dai sistemi professionali che cercano di
difendersi dall'accesso di persone non autorizzate a dati
eventualmente riservati. Tipicamente ad ugni user corrispondono
dei pezzi di disco (Subdirectory) alle quali si puo' accedere ed
un sottoinsieme dei comandi del sistema operativo che possono
essere eseguiti.
A meno che il sistema chiamato non abbia impostato degli user
specifici, cosa poco utile nel nostro campo, i due user piu'
comuni sono:
guest e anonymous
Questi due utenti possono essere usati con pasword
qualunque...tanto non viene controllata e tipicamente accedono
alla subirectory ...\....\public.
FTP
L'FTP e' l'applicativo di file transfer attraverso la rete. Con
l'FTP si possono trasferire sia file ASCII (default) che file
binari. Poiche' il traferimento di lunghi file potrebbe
intasare la rete l'FTP ha dei meccanismi suoi propri per evitare
questo spiacevole effetto: se gli OK di ricezione dalla stazione
rivevente arrivano in ritardo l'FTP rallenta ulteriormente
l'invio dei dati successivi. Qesto e' il meccanismo di "back
off" ed e' di fondamentale importanza per preservare la
funzionalita' della rete. Ovviamente la performance dell'FTP e'
di gran lunga inferiore a quella di YAPP su una connessione
punto-punto. Il motivo e' ovvio: La rete che c'e' di mezzo, se
non ben dimensionata, ha una capacita' di traffico molto
limitata ed ogni accenno di intasamento provoca un rallentamento
accellerato del trasferimento a causa del back off. Comunque
quello dell'FTP e' il giusto comportamento quando si considera
che la rete e' uno strumento condiviso fra tantissimi utenti e
che, quindi, ad ognuno deve essere data la possibilita' di
usufruirne senza che nessuno possa spadroneggiare.
Anche l'uso dell'FTP e' piuttosto facile: ci si collega al
computer remoto col comando
> ftp iw1ppb
per esempio. Dopo la sequenza di login si e' in modo comando e
si possono dare al computer remoto una certa serie di comandi.
Per esempio si possono listare i file presenti sulla
subdirectory remota col comando "dir" od il tipico unix "ls".
Prima di iniziare un trasferimento di file bisogna sapere se il
file in questione e' di tipo testo, cio' composto da soli
caratteri ASCII e terminato dal carattere Ctl-Z oppure se si
tratta di un file binario...tipicamente un programma. Nel
secondo caso bisogna richiedere espressamente il trasferimento
binario col comando:
> type i
Per inviare uno dei propri file al computer remoto si da' il
comando:
> put nome_file_qui' nome_file_la'
Al contrario, per prelevare un file dal computer remoto si da'
il comando:
> get nome_file_la' nome _file_qui'
I "nome_file.." eventualmente contengono l'intero path, ossia
il percorso nelle subdirectory.
I comandi "put" e "get" a loro volta aprono un'altra sessione di
tipo DATA che rimane attiva insieme alla predente di controllo
fino alla fine del trasferimento.
SMTP
Il terzo degli applicativi fondamentali e' l'SMTP che provvede
all'invio ed alla ricezione di brevi messaggi personali. La
scrittura e la lettura di tali messaggi avviene al difuori del
programma NET. Infatti occorre lanciare il programma BM per
comporre un testo da inviare o per listare e leggere i messaggi
ricevuti.
NET automaticamente provvede ad inviare eventuali messaggi in
attesa o a ricevere quelli in arrivo. Il sistema SMTP puo' in
futuro rimpiazzare egregiamente il servizio fatto dai BBS col
comando SP. Infatti nell'attuale sviluppo del programma NET di
KA9Q (versione NOS) e' stato introdotta una funzione BBS che
permette ad un utente AX.25 dotato di un normale TNC, di
accedere alla funzione BBS a da li' utilizzare l'SMTP per
inviare messaggi agli utenti collegati alla rete.
In questo caso la rete e' vista come in Fig. 8.2. dove
l'accesso avviene attraverso opportuni nodi dedicati ad
interfacciare da una parte gli utenti e dall'altra la rete.
Tali nodi, tipicamente stazioni dotate di computer con tcp/ip e
varie radio, sono stazioni di pubblico servizio capaci di
fornire l'accesso alla rete sia ai normali TNC AX.25 che ad
utenti piu' evoluti.
Uno di tali utenti, per esempio, puo essere un BBS che fa
forwarding attraverso la rete con gli altri BBS e parla, a sua
volta, su una frequenza riservata con i suoi propri utenti. Un
service provider potrebbe al contrario, fornire un servizio agli
utenti tramite la rete. Questo potrebbe essere un computer
dotato di Data Base Call Book interrogabile, appunto, attraverso
la rete anche da un utente AX.25.
La realizzazione dei nodi di accesso e' in fase di avanzata
realizzazione da parte di N3EUA e soci utilizzando un super TNC
di nuova progettazione basato sul processore Motorola 68302.
Tale TNC sara' in grado di eseguire da solo il programma NET di
KA9Q opportunamente adattato e senza l'uso di dischi. Questo
progetto e' stato battezzato NOSINABOX.
PING
Questo e' un applicativo semplicissimo che serve solo a
verificare se un certo utente della rete e' attivo ed in quanto
tempo un messaggio va e viene attraverso la rete. E' utile per
verificare anche lo stato di intasamento della rete.
ECHO
Con questo applicativo la stazione chiamata fa l'eco di tutti
i caratteri che riceve.
DISCARD
Tutti i caratteri ricevuti vengono buttati via.
FINGER
Pernette di avere le informazioni su un utente leggendo un
piccolo file appositamente scritto. Se fate FINGER i2kfx
potrete leggere i miei dati anagrafici equali sono i miei
interessi nel campo delle radio.
----- ** ------
Tutti questi applicativi "standard" vengono richiamati
collegandosi ad un opportuno socket nel programma che gestisce
il tcp/ip. Per le funzioni dei socket rimando a R.R. 6/90
p.38.
Oltre a questi sono possibili altri applicativi scrivibili per
funzioni ad hoc che usano socket liberi. Uno che ha
particolarmente colpito la mia fantasia e' quello descritto da
KA6NAN e WA8DZP dedicato al gioco degli scacchi fra due OM.
Questo applicativo mostra sugli schermi delle due stazioni
collegate la scacchiera ed i suoi pezzi. Col mouse e' possibile
fare le mosse e queste automaticamente vengono riprodotte sulla
scacchiera dell'avversario grazie all'invio delle nuove
coordinate del pezzo. Un'apposita finestrella, poi, permette
anche lo scambio di messaggi fra i due giocatori.
Applicativi di questo tipo, in cui l'utente ha un'interfaccia
grafica, possono essere pensati anche per altri servizi fra i
quali quelli di "emergenza" hanno un particolare interesse. Per
esempio la posizione di veicoli o di incidenti potrebbe essere
trasmessa inviando via radio il codice identificativo di una
cartina e le coordinate su di essa. Il programma ricevente
avrebbe solo da estrarre dal suo disco la cartina indicata, e
mostrarla all'operatore con la posizione esatta dell'evento
messa in evidenza.
Un esempio di applicativo "Service Provider" e' quello
realizzato da N6OYU e WA8DZP chiamato Callsign Server.
Utilizzando una versione modificata del comado FINGER questi OM
hanno messo in funzione una stazione che quando interrogata
invia tutti i dati disponibili dal Call Book americano per l'OM
richiesto . Questo applicativo si basa su un database costruito
sul file fornito dall'FCC, lungo 108 Megabyte, e memorizzato su
un Macintosh con disco da 300Mb. L'utente che vuole sapere
tutto su su wa8dzp, per esempio, da' il seguente comando:
net> finger %wa8dzp@n6oyu
In risposta, dopo la connessione, si ricevono tutte le
informazioni su wa8dzp contenute nel database. (Fig. 8.3)
Ovviamente questo e' solo un semplice esempio che si potrebbe
espandere con maggiori informazioni ed i campi di interesse e le
esperienze fatte.
POP2
Nelle ultime versioni del NET e' stato aggiunto il POP2 che puo'
essere di grande interesse per il nostro tipo di rete e di
utilizzo.
Il POP2 e' un servizio aggiuntivo all'SMTP e permette ad una
stazione di uso pubblico, e, quindi, sempre in funzione, di
conservare i messaggi personali per le stazioni che sono attive
solo poche ore al giorno: i tipici utenti occasionali del
servizio.
Quando un utente POP2 accende il proprio PC avviene il
trasferimento dei messaggi dalla stazione pubblica all'utente.
La cosa e' molto simile a quello che fanno alcuni PBBS verso i
BBS.
**********************************************************************
Elenco aggiornato dei numeratori TCP/IP
Da Pino Zollo I2KFX [44.134.2.2] Numeratore Italiano TCP/IP ( e zona 2 )
I2KFX Pino Zollo Via Negrelli,21 20052 Monza tel. 039-833431 BBS @ik2hdg-8
Numeratori regionali alla data (24/01/91)
I0VUQ Alessandro Surian Via San Paolo Apostolo,65 00040 S.Maria delle Mole
(Roma) tel. 06-9351825
I1EXH Danilo Benedetto Strada del Salino,51 10133 Torino tel. 011-6967755
IW1PPB Andrea Olivero Via Manzoni 7 Loano tel.019-673106 BBS @I1ICZ o
@IR1SVT
IV3PFF Furio Merco Via Meutana,47 33100 Udine tel. 0432-35544 BBS @IV3PPF
IW4ANU Giorgio Tovoli Via Andrea Costa,129 40134 Bologna tel. 051-424477
IK5LZC Stefano Saccardi Via L. Boccherini,17 50144 Firenze Tel. 055-362524
BBS @ I5SGG
I6LMQ Lello Mastropietro Via Monfalcone,7 66023 Francavilla al Mare
tel. 085-810498 BBS @i6lmq-8
IW7BBB Mariano Caputo Via Gianicolo 10/6 70053 Canosa di Puglia
tel.0883-612279
I8EJC Cesare Cordopatri Via Anile 15 88026 Pizzo Calabro (CZ)
tel. 0963-531591 BBS @it9eoy
IT9EYQ Cosimo Flaccomio Via G.Garibaldi,508 98050 Barcellona
tel. 090-9762735 BBS @it9ygm.me.ita
**********************************************************************
Le ultime dal COORDINAMENTO
Il 19/1 si e' svolta a Milano la riunione di coordinamento
Lombardia. In tale occasione e' stato riconfermato I2NOS
coordinatore regionale. Oltre ad altre decisioni e' stato
iniziato un riassetto del Band Plan del packet in 144 MHz: in
particolare e' stato deciso di abbandonare la frequenza di
144.600 per lasciarla ai cultori della RTTY come previsto dal
Band Plan internazionale. Il BBS di Milano ik2anp-8,
(prossimamente ik2hng-8) si sposta a 144.610 in USB e si decide
di iniziare a sperimentare l'inserzione di canali SSB fra sue FM
allo scopo di avere piu' spazio in questa banda nell'ottica di
una graduale migrazione dall'FM all'SSB.
Il 26/1 si e' svolta a Roma la riunione dei comitati regionali
ARI. In questa occasione I2KFX ha illustrato ai presenti gli
obbiettivi ed i modi della costruenda organizzazione di
Coordinamento Packet.
Il 27/1 si e' svolta a Bologna la riunione del coordinamento
Emilia Romagna. In tale riunione e' stato eletto coordinatore
regionale Gianni I4QHD. Anche in questa riunione si e' deciso di
liberare la frequenza 144.600 e di uniziare ad usare l'SSB.