ADPnetwork:
concludendo

Siamo finalmente giunti all'ultimo appuntamento, su queste pagine, riguardante la nostra rete fault tolerant per computer Amiga. In quest'articolo faremo una specie di riassunto generale, non tanto dal punto di vista tecnico-implementativo, ma da quello dell'utente collegato (giustamente) in rete.

Differentemente, poi, da quanto annunciato lo scorso mese, non siamo ancora in grado di fornirvi particolari sulla commercializzazione del prodotto (con l'estate di mezzo, proprio non e' il caso...) ma possiamo sicuramente anticiparvi che ADPnetwork avra' sicuramente un prezzo molto, molto "politico".

Resta comunque valido l'invito, rivolto a tutti gli interessati, a prendere direttamente contatto col sottoscritto qui in redazione per qualsiasi tipo di chiarimento riguardante la rete.

Presente e futuro

Come piu' volte riferito nei precedenti articoli, ADPnetwork utilizza attualmente l'interfaccia seriale a 31250 baud quale link fisico tra i vari nodi. A causa di questa limitazione hardware imposta dall'architettura Amiga non siamo riusciti a spingerci oltre tale velocita', ma stiamo studiando gia' da un pezzo una scheda hardware che, oltre a spingere la rete ad una velocita' piu' di trenta volte superiore, eseguira' autonomamente il forward di tutti i messaggi in transito per i nodi. Contiamo, tra l'altro, di essere pronti con la versione hw addirittura al prossimo SMAU dove invitiamo tutti gli interessati a venirci a trovare nel nostro stand.

Attualmente con una rete software a 31250 baud possiamo sbizzarrirci quando le operazioni da compiere non sono particolarmente "lunghe". Quindi per applicazioni dove sono richieste "tante" operazioni "brevi" non esistono particolari problemi. Diciamo che accedere ad un file presente su un hd disponibile su una macchina remota e' quasi come accedere ad un file presente su una unita' a floppy disk locale.

In pratica e' sempre meglio di correre da una macchina all'altra col floppyno in mano per effettuare i trasferimenti di file.

Con la futura (ma non troppo) versione hardware non ci saranno piu' limitazioni di alcun tipo. Nel vero senso della parola potremo, da ogni macchina in rete, contare su tutti i device disponibili su tutte le macchine, come fossero nostri device senza notare alcun degrado delle prestazioni dovute alla presenza della rete. Certo se piu' macchine accedono alla stessa unita' questa dovra' servire piu' richieste contemporaneamente con conseguenti ritardi sull'esecuzione, ma questo banalmente gia' succede anche su un singolo Amiga quando piu' processi in esecuzione su quella macchina accedono allo stesso device.

In altre parole, montando ADPnetwork su un certo numero di macchine cio' che otteniamo e' un nuovo ambiente multiuser, multiprocessor, sul quale grazie al net handler di Ciuchini e Suatoni possiamo addirittura contare su un file system distribuito, completamente compatibile con tutto il software gia' esistente. Ma questo e' l'argomento del prossimo paragrafo...

Compatibilita'

In un certo senso dobbiamo ringraziare ancora una volta il sistema operativo di Amiga e la sua possibilita' di montare facilmente nuovi device. Chi segue Amiga dai tempi del 1000 e del software di sistema versione 1.1 ricordera' che allora gli unici device disponibili erano i floppy disk (df0:...df3:) la ram disk (RAM:), le porte seriale e parallela (SER:, PAR:) e il driver di stampa (PRT:). Non esisteva ancora la mountlist e per aggiungere un nuovo device bisognava smanettare nelle liste di sistema con appositi programmi ad hoc.

Poi con le release 1.2 e 1.3 sono nati tutta una serie di nuovi device (PIPE:, AUX:, VD0:, SPEAK:, ecc.ecc.) che spingevano l'utilizzo del file system anche verso nuovi orizzonti. Quando poi i vari handler erano davvero AmigaDOS-compatibili le funzioni offerte rasentano l'incredibile. Pensate ad esempio a CrossDos che monta due nuovi device "A:" e "B:" per una perfetta compatibilita' col file system MS-DOS. Caricate sul vostro Amiga un qualunque WP e, inserito un dischetto MS-DOS nel drive "DF0:", chiedete di leggere o salvare un file nel device "A:" di CrossDos: il WP eseguira' senza nemmeno pensare (ammesso che sia possibile) di leggere o salvare file in formato MS-DOS. Tutti i comandi che AmigaDOS mandera' al device "A:" saranno trasformati dall'handler di questo in comandi "compatibili" col formato del disco inserito nel drive che nulla ha a che vedere, appunto, con AmigaDOS.

Cosi' un qualsiasi programma nato per girare e utilizzare file in formato AmigaDOS grazie all'aggiunta di un handler e' in grado di leggere e scrivere file in un formato completamente diverso.

Grazie a questo meccanismo e' nato il device "net:" che identifica, appunto, la nostra rete. Questo e' visto dal sistema operativo di Amiga come una normalissima unita' a dischi sulla quale sono possibile praticamente tutte le operazioni normalmente possibili su dischi. E se da shell diamo un bel 

dir net:

oppure la sequenza di comandi:

cd net:

dir

vedremo comparire la lista di tutte le macchine collegate in rete come fossero tante directory dell'unita' "net:".

Analogamente possiamo listare una di queste directory nei due modi gia' indicati (posto che una macchina si chiami "platone"):

dir net:platone

oppure, procedendo con i cd:

cd platone

dir

in tutt'e due i casi vedremo la lista dei device disponibili sulla macchina platone, ancora come subdirectory. Possiamo continuare la nostra esplorazione sulla rete, accedendo ad esempio all'hd della macchina platone per vedere cosa c'e' dentro. Sempre con i due metodi daremo:

dir net:platone/dh0

oppure, continuando a spostare la nostra CurrentDir:

cd dh0  (attenzione: senza i ":" dal punto di vista nostro si tratta di una normale directory, non di un device) seguito da un "dir".

Cosi' il path completo del file "pippo" contenuto nella directory "temp" dell'hd della macchina platone sara':

net:platone/dh0/temp/pippo

e per visualizzarlo sara' sufficiente scrivere

type net:platone/dh0/temp/pippo

o se avevamo proceduto a colpi di cd ed eravamo rimasti all'ultimo "cd dh0" bastera' digitare

cd temp

type pippo

oppure:

type temp/pippo

insomma, come piu' ci aggrada.

Da ogni macchina possiamo addirittura aggiungere al nostro path di ricerca anche directory presenti su dischi remoti cosi' come assegnare simboli "remoti". Facciamo un paio di esempi.

Immaginiamo che nella macchina platone, o meglio nel suo hd, vi sia una nutrita serie di programmi che vogliamo "vedere" sempre anche dalla nostra postazione. Diciamo che questo programmi stanno nella directory "tools". Scrivendo sulla nostra:

path net:platone/dh0/tools add

ogni comando che digiteremo da quel momento in poi sara' cercato anche sulla macchina remota (nella directory tools) per essere eseguito. Analogamente possiamo assegnare simboli:

assign c: net:platone/dh0/c

assegnera' la nostra directory dei comandi "c:" alla directory c dell'hd della macchina platone. Da quel momento in poi ogni comando eseguito da shell verra' prima caricato dalla macchina platone e poi eseguito sulla nostra macchina.

Cosi' ogni programma, in grado di vedere device montati (la quasi totalita' del sw esistente) sara' compatibile con la nostra rete: basta solo indicare path "di rete". Facciamo un esempio, chiamando a testimoniare il nostro fiore all'occhiello italiano "C1-Text". Montata la rete proviamo a leggere un file di testo dalla directory "s" della macchina pitagora col nostro C1-Text.

Caricato il programma, dal menu "Generale" scegliamo l'item "Aprire documento", come abbiamo sempre fatto. Prima novita': nel requester che appare, accanto alla scritta "unita' di memoria", oltre ai normali device disponibili troviamo un nuovo button indicante "net": e' il device della rete. Col mouse clickiamo su questo, e vedremo apparire la lista delle macchine in rete.

Sempre col mouse clickiamo su pitagora: immediatamente appare la lista dei device di questa macchina. Clickiamo su dh0 e poi (non appena apparsa la directory di questo hd remoto) sulla directory "s". Siamo arrivati, scegliamo il nostro file (ad esempio la startup-sequence di quella macchina) e clickiamo sul gadget "Procedere". C1-Text non lo sa, ma sta caricando un file dalla rete. Con un procedimento assolutamente analogo possiamo salvare il file da qualsiasi altra parte, sull'intera rete.

E' cosi' con qualsiasi altro programma, di qualunque genere, riguardo ogni possibile tipo di file da leggere o salvare su rete. Semplice, no?

Compatibilita' e WorkBench

Tutto quello che abbiamo detto riguardo l'utilizzo della rete da shell o dall'interno di qualsiasi programma commerciale permane anche nell'utilizzo via WorkBench.

Infatti, non appena entrati in rete (operazione demandata alla startup-sequence del disco di boot o a seguito dell'attivazione di una apposita icona), anche il WB mostrera' il nuovo device "net" come uno dei dischi accessibili. Se proviamo a clickare sull'icona "net", si aprira' una finestra contenente tante icone a forma di computer quante sono le macchine collegate in rete in quel momento. Se in seguito nuovi nodi si aggiungeranno alla rete, automaticamente questi saranno visibili dalle restanti postazioni come nuove icone nella finestra del device "net".

Come visto prima per le operazioni di shell, clickando sull'icona di uno dei computer in rete vedremo tutti i device di quella macchina. A questo punto un accesso ad una qualsiasi di queste icone sara' un accesso al corrispondente device remoto. Cosi' potremo copiare file da una macchina all'altra semplicemente spostando icone alla stessa maniera di come faremmo, su singola macchina, per spostare file da un device ad un altro.

Analogamente clickando sull'icona di un qualsiasi programma presente su un device remoto avremo l'effetto di caricarlo e lanciarlo sulla nostra macchina. Addirittura possiamo cancellare, rinominare, duplicare e chiedere informazioni su file remoti.

L'unica cosa che non possiamo fare e' formattare la rete...

A tutti i programmatori:

ADPnetwork e le applicazioni distribuite

ADPnetwork vera e propria e' una collezione di processi che pemette a qualsiasi programma in esecuzione su una macchina di dialogare con qualsiasi altro programma in esecuzione su un'altra macchina. In pratica i Net-Handler e i Net-Server di Ciuchini e Suatoni presenti su tutte le macchine collegate in rete utilizzano i processi di ADPnetwork per scambiarsi i Dos_Packet di AmigaDOS piu' altri messaggi.

Analogamente e' possibile scrivere qualsiasi altra applicazione distribuita utilizzando l'ultima versione dell'ADPmttb e disponibile, su richiesta e gratuitamente, a chiunque volesse sviluppare applicazioni su rete.

Molto semplicemente, se un processo della macchina platone deve mandare un messaggio sulla porta "pippo" di un processo in esecuzione sulla macchina pitagora sara' sufficiente utilizzare la funzione SendBlock con il suo nuovo "MODE_NET" nel seguente modo:

SendBlock(MODE_NET,"pitagora/pippo",Msg,Len);

dove "Msg" e' il puntatore al messaggio da spedire e "Len" e' la lunghezza dello stesso.

Complementarmente, il processo destinatario in esecuzione sulla macchina pitagora, oltre ad aver creato una porta MTTB di nome "pippo" attraverso la funzione "NewPort" effettuera' una semplice:

Len = ReceiveBlock(MODE_WAIT,"pippo",Msg);

Da segnalare che per il processo destinatario non cambia nulla se il messaggio ricevuto arriva da un altro processo in esecuzione sulla medesima macchina o da un processo remoto in esecuzione su un altro nodo: a "lui" e' arrivato un messaggio e basta. Poi, naturalmente, sara' cura del mittente indicare la vera provenienza all'interno della busta chiusa...

E allora perche' non cominciare gia' a pensare ad animazioni in tempo reale realizzate da piu' computer in rete, immagini ray tracing costruite parallelamente o, magari, a stupendi videogames multiutente con cui attrezzare vere e proprie sale gioco ?

Il limite, come sempre, la fantasia e l'inventiva di chi programma. Nulla di piu'.

Concludendo

In questo viaggio all'interno di Amiga iniziato circa un anno fa ci siamo sicuramente divertiti un sacco. ADPnetwork voleva essere inizialmente solo una esperienza didattica da rigirare a tutti i lettori "Amiga" di MC ma poi e' diventata, forse casualmente, qualcosa di piu'. Ne abbiamo avuto riprova tanto durante lo SMAU dell'89 dove era mostrato un vero prototipo, quanto scambiando impressioni "tecniche" con gli altri sviluppatori Amiga durante l'ultima DevCon di Parigi. Non ci rimane allora che darvi appuntamento sul numero di Settembre di MC per maggiori notizie sulla commercializzazione di ADPnetwork e al prossimo SMAU 90 per toccare finalmente con mano tutte le nostre parole di questi ultimi 10 mesi. Arrivederci...