COS'E' IL TCP/IP

                        INTRODUZIONE

                AI     PROTOCOLLI     INTERNET

             Computer  Science  Facilities  Group

              The State University of New Jersey

       Copyright (C) 1987 Charles L. Hedrick .

                     Tabella dei contenuti

1. Che cosa  e' TCP/IP?

2. Descrizione generale dei protocolli TCP/IP

 2.1 Il livello  TCP                        

 2.2 Il livello  IP                        

 2.3 Il livello  Ethernet                 

3. Porte o Sockets e Strati (Layers) applicativi

 3.1 Un esempio di applicativo: SMTP

4. Altri protocolli oltre il TCP: UDP  e  ICMP

5. Tenere traccia dei nomi e delle informazioni: Il sistema Domain    

6. Gli instradamenti

7. Dettagli sugli indirizzi Internet: Sottoreti e Broadcasting              

8. Frammentazione e Riassemblaggio di  datagrammi

9. Incapsulazione  Ethernet: ARP

10.Per ottenere maggiori informazioni

   Questo  documento  e'  una  breve  introduzione  al  TCP/IP,

seguito   da   un  consiglio  su  cosa  leggere  per   maggiori

informazioni.  Esso  non  deve essere inteso  come  descrizione

completa,  pero'  puo'  dare   un'  idea  delle  capacita'  dei

protocolli   descritti.  Se  comunque  fosse  necessario   ogni

dettaglio  di  questa  tecnologia,  ci  si  potra'  documentare

personalmente.

   In   tutto   il   testo,  si  troveranno  riferimenti   agli

standards,  nella  forma di "RFC + numero" o  "IEN  +  numero":

questi  sono numeri di documenti. La sezione finale  di  questo

documento spiega come ottenere copie di quegli standards.

   Infine,  laddove  il senso era generale, la parola  Computer

e' stata tradotta con la parola Calcolatore. Tuttavia compaiono

altre   denominazioni  per  indicare  un  "calcolatore",   come

"sistema"  o  "sistema di calcolo" o "micro" o "workstation"  o

altro ancora, sebbene a volte il significato varia leggermente.

   1. Che cosa e' TCP/IP?

   TCP/IP e'un insieme di protocolli sviluppati per ottenere la

cooperazione  tra calcolatori nella condivisione delle risorse

attraverso  la  rete.  E'  stata sviluppata  da   una comunita'

di ricercatori incentrata sulla rete  ARPA  che  e' sicuramente

la rete TCP/IP piu' conosciuta.

   Al  mese  di  giugno 1987, almeno 130 differenti rivenditori

avevano prodotti che supportano TCP/IP, ed infatti  migliaia di

reti di tutti i tipi lo usano.

   Prima  si  daranno alcune definizioni di base. Il nome  piu'

preciso per il gruppo di protocolli che si sta per descrivere e'

"Internet Protocol Suite".

   TCP  e  IP,  due  dei  protocolli  del  gruppo  che  saranno

descritti  fra  poco, sono i piu' conosciuti e percio'  diventa

comume  usare  il termine TCP/IP o IP/TCP per fare  riferimento

all'intera   famiglia:  non  vale  la  pena  criticare   questa

abitudine.  Comunque questo puo' portare  ad alcune  stranezze.

Per  esempio, si fa riferimento a NFS come se fosse  basato  su

TCP/IP,  anche  se  non usa il TCP       (infatti  usa  IP)  ma

impiega  un  protocollo  alternativo anzicche'  il  TCP.  Tutte

queste sigle saranno decifrate nelle pagine seguenti.

   L'Internet  e'  un insieme di reti, che comprende:  Arpanet,

NFSnet,reti regionali come Nysernet,reti locali (LAN) presso un

certo  numero di universita' ed istituzioni di  ricerca,  e

diverse reti militari.

   Il  termine "Internet" fa riferimento all'intero  gruppo  di

reti. Il sottogruppo di queste, che e' diretto dal Dipartimento

della Difesa, si riferisce al "DDN" (Defense Data Network). DDN

include  alcune  reti orientate alla ricerca, come  Arpanet,  e

quelle  strettamente militari (poiche' molti dei fondi  per  lo

sviluppo  dei  protocolli Internet arriva dalla  Organizzazione

DDN  i  termini  Internet e DDN possono qualche volta  sembrare

equivalenti). Tutte queste reti sono connesse l'un l'altra. Gli

utenti  possono mandarsi messaggi da una all'altra e viceversa,

eccetto  dove  c'e' sicurezza o altra politica  di  restrizione

sull'accesso.

   Ufficialmente parlando, i documenti sui protocolli  Internet

sono  semplicemente  degli standards adottati  dalla  Comunita'

Internet  per  i propri usi. Piu' recentemente il  Dipartimento

della Difesa ha pubblicato un documento: "Milspec definition of

TCP/IP". Esso e' una definizione piu' formale e appropriata per

l'uso nell'acquisto delle specifiche.  Comunque molte comunita'

continuano ad usare gli standards Internet. La versione Milspec

e' coerente con questi.

   Comunque  si  chiami, TCP/IP e' una famiglia di  protocolli.

Alcuni  forniscono delle funzioni al livello  basso  necessarie

per  molte applicazioni che includono IP, TCP, e UDP e  saranno

descritti un po' piu' dettagliatamente in seguito . Altri  sono

protocolli  per  effettuare dei compiti  precisi  per  esempio:

trasferimento di files tra calcolatori, spedizione di  posta, o

ricerca di chi ha avuto accesso in un altro calcolatore.

   Inizialmente   il   TCP/IP   era   usato   soprattutto   tra

minicomputers e mainframes che sono macchine con  dischi propri

e generalmente entro-contenuti.

   Cosi  i  servizi   TCP/IP tradizionalmente  piu'  importanti

sono:

  -  trasferimento di files. Il protocollo  trasferimento

     file  (FTP)  permette  ad  un  utente  su  un  calcolatore

     qualsiasi  di  ricevere  o mandare  files  da/a  un  altro

     calcolatore.

        La  sicurezza  si  realizza richiedendo  all'utente  di

     specificare il nome e la parola chiave.

        Disposizioni  sono state prese per il trasferimento  di

     files  tra  macchine con differenti insiemi di  caratteri,

     convenzioni  di fine linea, etc. Esse non sono  le  stesse

     prese  per il recente "file system di rete" o i protocolli

     "netbios", i quali saranno descritti piu' sotto.

        Piuttosto,  FTP  e'  un'utilita' che si  puo'  attivare

     ogni  volta che si vuole accedere ad un file su  un  altro

     sistema  di  calcolo. Lo si usa per copiare un file  sulla

     propria macchina per poi lavorare sulla propria copia  (si

     veda  RFC 959 per le specifiche su FTP).

    -  accesso  remoto  (remote login).  Il  protocollo  di

     terminale  chiamato anche TELNET permette ad un utente  di

     accedere su qualsiasi altro calcolatore in rete.

        Si  inizia una sessione remota specificando il nome del

     calcolatore  al  quale ci si intende  collegare.  Da  quel

     momento fino a che non finisce la sessione, qualsiasi cosa

     si  digiti  sulla tastiera viene inviata al corrispondente

     calcolatore.  Da notare che il colloquio  avviene  con  la

     propria  macchina, ma il programma telnet  fa  si  che  il

     proprio calcolatore sia trasparente nella sua azione. Ogni

     carattere che si digita viene inviato all'altro sistema.

        Generalmente,  la connessione verso il  sistema  remoto

     assomiglia  molto  ad una collegamento con  selezione  del

     circuito telefonico. Cioe', il sistema remoto chiedera' di

     accedere  con un nominativo e una parola chiave,  come  lo

     avrebbe normalmente chiesto ad un utente che avesse appena

     chiamato  via  modem. Quando ci si disconnette  dall'altro

     calcolatore, il programma telnet esce dal corrispondente e

     quindi ci si ritrova a colloquiare con il proprio.

        L'implementazione   su   microcalcolatore   di   telnet

     generalmente include un emulatore di terminale per  alcuni

     tipi comuni (si vedano RFC 854 e 855 per le specifiche  su

     telnet.  A  proposito: il protocollo telnet  non  dovrebbe

     essere  confuso con Telenet che e' un prodotto dei servizi

     commerciali di rete).

     -  posta elettronica. Questa applicazione permette  di

    mandare messaggi  ad utenti su altri calcolatori.

       Originariamente, c'era la tendenza ad usare solo  uno  o

    due  specifici  calcolatori. Cioe' si mantenevano  i  files

    della  posta  su  quelle  macchine.  Il  sistema  di  posta

    elettronica,    da'   semplicemente  la   possibilita'   di

    aggiungere un messaggio tra i files della posta  dell'altro

    utente.

       Pero'  ci  sono alcuni problemi in proposito  quando  si

    impiegano  microcomputers (PC). Il problema piu'  serio  e'

    che  un  micro  non e' adatto a ricevere posta elettronica,

    almeno  direttamente. Quando si manda  posta,  il  software

    preposto   presume  di  essere  in  grado  di  aprire   una

    connessione con il calcolatore dell'indirizzo. Se questo e'

    un  micro,  potrebbe essere spento, oppure potrebbe  essere

    impegnato  con  un altro applicativo, diverso  dalla  posta

    elettronica.  Per questa ragione, la posta e'  trattata  da

    sistemi  piu'  grandi,  dove  e'  piu'  pratico  avere   un

    dispositivo (server) per la posta che sia sempre attivo. Il

    software   per  la  posta  su  micro  allora   diventa   un

    interfaccia  utente  che rintraccia  la  posta  dal  server

    apposito  (si  vedano le RFC 821 e 822  per  le  specifiche

    sulla  posta  tra  calcolatori. Si  veda  RFC  937  per  il

    protocollo POP, studiato apposta per la lettura della posta

    su microcomputer).

   Questi   servizi   dovrebbero  essere   presenti   in   ogni

implementazione  TCP/IP,  eccetto quelle  per  micro  (PC)  che

possono  non supportare la posta elettronica. Tali applicazioni

tradizionali  giocano  ancora un ruolo molto  importante  nelle

reti basate su TCP/IP.

   Comunque  piu' recentemente, il modo in cui le reti  vengono

usate  sta'  cambiando. Il vecchio modello, in  cui  esiste  un

certo  numero  di  grossi  e  autosufficienti  calcolatori,  e'

iniziato  a  cambiare. Oggi molte installazioni, dispongono  di

molti  tipi  di calcolatori, incluso parecchi microcalcolatori,

stazioni   di   lavoro   (workstations),   minicalcolatori,   e

mainframes. Essi, sono probabilmente configurati per effettuare

attivita'   specifiche.  Ebbene,  quegli   stessi   calcolatori

chiameranno un altro sistema nella rete per chiedere  un  altro

servizio specializzato.

     Cio'  ha portato al modello " client - server" dei servizi

di  rete.  Un  server  e' un sistema che fornisce  un  servizio

specifico  per  il  resto della rete. Un  client  e'  un  altro

sistema  che usa quel servizio. Da notare che server  e  client

non  e'  necessario  che siano su differenti calcolatori:  essi

possono  essere  differenti programmi che girano  sullo  stesso

calcolatore.

   Ecco  di  seguito i tipi di server tipicamente  presenti  in

una  moderna installazione di computer. Da notare che i servizi

sottoelencati possono essere tutti forniti entro  la  struttura

di TCP/IP.

        -  file  system  di  rete (NFS). Esso  permette  ad  un

     sistema   di  accedere  ai  dati  (files)  su   un   altro

     calcolatore  in uno stile piuttosto integrato  rispetto  a

     FTP.

        Un  file  system  di  rete fornisce l'illusione  che  i

     dischi   o   altri   dispositivi  di  un   sistema   siano

     direttamente connessi ad altri.

        Non  c'e'  bisogno di utilizzare speciali  utilita'  di

     rete  per  accedere  ad un file su un  altro  sistema.  Il

     calcolatore pensera' semplicemente di avere alcuni  dischi

     in  piu'.  Questi dischi extra, "virtuali", si riferiscono

     agli  altri  dischi dei sistemi o parte  di  questi.  Tale

     capacita'   e'  utile  per  diversi  propositi.   Da'   la

     possibilita'   di  collegare  grossi  dischi   su   alcuni

     calcolatori,  consentendo  tuttavia  altri  accessi   allo

     spazio  sul  disco.  A parte gli ovvi benefici  economici,

     questo  sistema  permette a molta  gente  di  lavorare  su

     diversi calcolatori  per dividere files comuni. Esso rende

     il  sistema di manutenzione ed il salvataggio dei dati  di

     lavoro  (BACKUP) piu' facile, consentendo di  non  doversi

     preoccupare  di  registrare e fare  copie  del  lavoro  su

     diverse macchine.

        Diversi   rivenditori  e  distributori,  oggi   offrono

     calcolatori senza dischi ad alte prestazioni. Infatti essi

     non  hanno  affatto dischi: sono completamente  dipendenti

     dai dischi attaccati al "file server" comune

        Si  vedano  le  RFC 1001 e 1002 per la descrizione  del

     protocollo    NetBIOS   su  TCP  orientate   ai   personal

     computers.  Nelle  aree ove sono presenti  workstations  e

     microcalcolatori, e' molto probabile che sia usato il file

     system della SUN Microsystem. Le specifiche del protocollo

     NFS, sono disponibili appunto presso " SUN Microsystem ".

        -   stampa   remota.  Questo  protocollo  permette   di

     accedere  alle  stampanti attaccate su altri  calcolatori,

     come se fossero attaccate direttamente al proprio.

        Il  protocollo  piu'  usato e'  LPR  che  proviene  dal

     sistema operativo "UNIX di Berkeley ". Sfortunatamente non

     e'  molto  diffusa la relativa documentazione. Tuttavia  i

     files  sorgente in linguaggio C sono facilmente ottenibili

     dall'Universita'  di   Berkeley, al  fine  di  rendere  le

     implementazioni comuni .

       -  esecuzione remota, RPC. La presenza di questo server

     permette di richiedere che un particolare programma  venga

     processato su un differente calcolatore.

        Cio'  e'  utile quando si deve effettuare molto  lavoro

     su  di  un piccolo calcolatore, e parte di questo richiede

     invece le risorse di un grosso sistema.

       Ci  sono  diversi  tipi  di esecuzione  remota.  Alcuni

     operano  su  comandi  base.  Cioe'  si  richiede  che  uno

     specifico   comando  o  un  gruppo  di   comandi   vengano

     processati su di uno specifico calcolatore (versioni  piu'

     sofisticate   scieglieranno   un   sistema   che   diviene

     disponibile). Comunque ci sono anche dei sistemi "RPC" che

     permettono  ad  un programma di richiamare una  subroutine

     che funzionera' su un altro calcolatore.

        Ci sono molti protocolli di questa specie.

       Il  sistema  operativo  Unix di Berkeley  contiene  due

     servers  che  eseguono  comandi in modo  remoto:  "rsh"  e

     "rexec".  Le  pagine nel manuale, descrivono i  protocolli

     che essi usano.

       Il  software  per  l'utente su Berkeley  Unix  versione

     4.3,   contiene  un  interprete    di    comandi   (shell)

     distribuito che assegna  compiti e  lavori tra  un  gruppo

     di sistemi, a seconda del carico.

       I  meccanismi RPC sono stati argomento di  ricerca  per

     diversi  anni,  percio'  molte  organizzazioni  hanno   le

     realizzazioni (implementazioni) di tali servizi.

        I    piu'    diffusi    protocolli    RPC    supportati

     commercialmente, sembrano essere: Courier di Xerox  e  RPC

     di  SUN  e  i  relativi documenti sono disponibili  presso

     Xerox  e  Sun. Esiste comunque un implementazione pubblica

     di  Courier su TCP come parte di un pacchetto software  su

     Berkeley  Unix 4.3. Una implementazione di  RPC  e'  stata

     depositata su Usenet da Sun, e appare anche come parte  di

     un pacchetto software su Berkeley Unix 4.3.

       -  server dei nomi. Nelle grosse installazioni, ci sono

     diversi  gruppi  di di nomi che devono essere  manipolati.

     Essi  includeono  utenti e le loro  parole  chiave,  nomi,

     indirizzi  di  reti  per calcolatori e  descrizione  degli

     utenti (accounts).

        Diventa  molto  tedioso  mantenere  tutti  questi  dati

     aggiornati su tutti i calcolatori. In questo modo i  data

     base  sono  tenuti su un piccolo numero  di  sistemi.  Gli

     altri vi accedono ai dati attraverso la rete .

       Le  RFC  822 e 823 descrivono il protocollo del  server

     dei  nomi  usato per tenere traccia dei nomi  di  hosts  e

     indirizzi Internet sulla propria rete. Questa e' una parte

     adesso richiesta  da ogni implementazione TCP/IP. IEN  116

     descrive  un  vecchio protocollo del server dei  nomi  che

     viene usato da alcuni terminal-server e altri prodotti per

     cercare nomi  di hosts.

        Invece,  il  sistema "Pagine Gialle  (Yellow  Page)  di

     Sun"  e'  stato  progettato come meccanismo  generale  che

     manipola  nomi  di  utenti, gruppi  che  condividono  dati

     comuni,  ed altri data-base comunemente usati  dal sistema

     Unix.  Esso  e'  largamente disponibile in  commercio.  La

     definizione del protocollo e' disponibile presso Sun.

       -  terminal  servers.   In molte installazioni  non  si

     connettono  piu' i terminali direttamente ai  calcolatori,

     ma    ai    terminal-servers.   Un   terminal-server    e'

     semplicemente  un piccolo calcolatore che mantiene  attivo

     il  programma  telnet (o usa qualche altro protocollo  per

     l'accesso remoto).

        Se  un  terminale e' connesso ad uno di questi sistemi,

     basta  semplicemente digitare il nome  di  un  calcolatore

     per  essere  connessi. Generalmente  e'  possibile  tenere

     connessioni attive con piu' di un calcolatore allo  stesso

     tempo.

        Il  terminal-server  ha la capacita'  di  scambiare  le

     connessioni   rapidamente  e  avvisare  quando   l'output,

     proveniente  da  un'  altra  connessione,  e'  in  attesa.

     Inoltre  tutti  i veri terminal-server, dovrebbero   anche

     supportare  il  servizio di traduzione dei  nomi  e  altri

     protocolli.

        -  sistemi a finestre orientati alla rete. Fino a  poco

     tempo   fa,  i  programmi  grafici  ad  alte  prestazioni,

     dovevano  essere eseguiti su calcolatori che avessero  uno

     schermo grafico "a mappa di bit" direttamente attaccato  a

     questi.  I sistemi a finestre per la rete (network  window

     systems)  permettono ad un programma di usare uno  schermo

     su  un  altro  calcolatore. Nel contesto,  questo  sistema

     fornisce  un'  interfaccia  che  consente  di  distribuire

     lavori ai sistemi che sono piu' adatti a svolgerli,  dando

     tuttavia, un singola interfaccia grafica utente

        Il  sistema  a  finestre piu' implementato  e'  X.  Una

     descrizione di questo  protocollo e una implementazione di

     riferimento  sono  disponibili presso  il  gruppo  Project

     Athena  di MIT. Diversi venditori stanno anche supportando

     NeWS, un sistema a finestre definito da SUN.

        Entrambi  questi  sistemi  sono  stati  progettati  per

     usare TCP/IP.

   Da  notare  che alcuni dei protocolli descritti sopra,  sono

stati progettati da Berkeley, Sun , o altre organizzazioni. Per

questo  non  fanno ufficialmente parte del gruppo di protocolli

Internet.  Tuttavia  essi sono stati realizzati  con  l'uso  di

TCP/IP,  proprio come lo sono i normali protocolli  applicativi

TCP/IP.   Inoltre,  poiche'  le  loro  definizioni   non   sono

considerate   proprietarie   e   poiche'   le   implementazioni

commercialmente  supportate  sono  largamente  disponibili,  e'

ragionevole pensare che tali protocolli facciano effettivamente

parte dell'insieme Internet.

   Da  notare che la lista sopra presentata e' semplicemente un

saggio del tipo di servizi disponibili attraverso TCP/IP  anche

se  descrive gran parte delle maggiori applicazioni. Gli  altri

protocolli  comunemente  usati,  tendono  a  svolgere   compiti

specializzati per ottenere informazioni di vario tipo, come chi

e' presente nel sistema, qual'e' l'ora e la data, etc.

   Comunque per i servizi che non sono stati elencati  qui,  si

incoraggia   la  consultazione  della  corrente   edizione   di

"Protocolli  Internet"  (attualmente  RFC  1011).  Esso  elenca

diverse caratteristiche dei protocolli disponibili, e raccoglie

le  osservazioni su alcune delle maggiori implementazioni  allo

scopo di notare cio' che i vari venditori hanno aggiunto.

   2. Descrizione generale dei protocolli TCP/IP

   TCP/IP  e' un insieme di diversi livelli di protocolli.  Per

capire  che  cosa questo  significhi, sara' utile osservare  un

esempio.

   Una   situazione   tipica  e'  spedire  posta   elettronica.

Dapprima  c'e'  un  protocollo per la posta  che  definisce  un

insieme  di  comandi che una macchina manda ad  un  altra,  per

esempio:  i  comandi  per specificare chi e'  il  mittente  del

messaggio, chi e' il destinatario e poi il testo del messaggio.

Questo  protocollo  presume che ci sia una  via  affidabile  di

comunicazione  tra  i  due calcolatori. La  posta,  come  altre

applicazioni, definisce semplicemente un gruppo  di  comandi  e

messaggi da mandare. Essa e' stata progettata per essere  usata

insieme a TCP ed IP. TCP e' responsabile nell'assicurare che  i

comandi  raggiungano  il  corrispondente.  Inoltre  TCP   tiene

traccia di cio' che viene spedito, e ritrasmette ogni cosa  non

recapitata. Se un messaggio e' troppo grande per un datagramma,

per  esempio il testo della posta, TCP lo dividera' in  diversi

datagrammi, e assicurera' che essi arrivino correttamente.

   Poiche'   queste   funzioni  vengono  richieste   da   molte

applicazioni,  esse sono state raccolte insieme  in  protocolli

separati, piuttosto che fare parte di specifiche per l'invio di

posta.

   Si  puo' immaginare TCP come una raccolta di routines che le

applicazioni  possono usare  quando esse hanno bisogno  di  una

comunicazione affidabile di rete con un altro calcolatore.

   Allo  stesso modo, TCP richiama i servizi di IP.  Sebbene  i

servizi  che  TCP offre siano necessari per molte applicazioni,

ci  sono  ancora alcuni tipi di applicazioni che non  ne  hanno

bisogno .

   Ci  sono  pure alcuni servizi che ogni applicazione richiede

e  percio' sono messi insieme dentro IP. Come succede con  TCP,

si  puo'  pensare  di IP come un insieme di  routines  che  TCP

richiama, ma che sono anche disponibili ad applicazioni che non

usino TCP.

   Questa   strategia   nel  costruire  parecchi   livelli   di

protocolli si chiama "stratificazione o layering".

   Si  considerino i programmi applicativi come la  posta,  TCP

ed  IP  come se fossero "strati o layers" separati, ognuno  dei

quali richiama i servizi dello strato inferiore.

   Generalmente, i programmi TCP/IP usano 4 strati:

        -un protocollo applicativo come la posta

        -un  protocollo come TCP che fornisce servizi richiesti

         da piu' applicazioni

        -un  protocollo  che  fornisce  il  servizio  base   di

         portare alla destinazione i datagrammi come IP

        -i  protocolli necessari a gestire uno specifico  mezzo

         fisico, come Ethernet o una linea punto a punto.

   TCP/IP  e'  basato sul modello "catenet" (esso e'  descritto

piu' dettagliatamente in IEN 48). Questo modello presume che ci

siano  molte  reti  indipendenti  connesse  insieme  attraverso

gateways  o routers. Infatti l'utente dovrebbe essere in  grado

di  accedere  ai  calcolatori o altre risorse su  qualunque  di

queste reti.

     Dunque  i  datagrammi  spesso  passeranno  attraverso  una

dozzina  di  differenti  reti  prima  di  raggiungere  la  loro

destinazione  finale.  Percio' l'instradamento  necessario  per

realizzare   il  collegamento,  dovrebbe  essere  completamente

invisibile   all'utente,  che  per  quanto  lo  riguarda   deve

conoscere solo "l'indirizzo Internet".

   Esso  e' un indirizzo che appare nella forma 128.6.4.194  ed

e'  esattamente  un numero a 32 bit. E' scritto  con  4  numeri

decimali, ognuno rappresentante 8 bits di indirizzo (il termine

ottetto  viene usato nella documentazione Internet per indicare

gruppi di 8 bits. Il termine "Byte" non viene mai usato perche'

TCP/IP e' supportato da alcuni calcolatori che hanno misure  di

byte diverse da 8 bits).

   Generalmente   la   struttura  dell'indirizzo   da'   alcune

informazioni su come raggiungere il sistema, per esempio  128.6

e'   un   numero  di  rete  assegnato  all'autorita'   centrale

dell'Universita' di RUTGERS. RUTGERS usa il successivo  ottetto

per   indicare  quale  rete  locale  ethernet  o  campus  viene

coinvolto. 128.6.4. e' una rete locale (LAN) ethernet usata dal

"Dipartimento  delle  Scienze dei Computer".  L'ultimo  ottetto

consente  la  numerazione fino a 254 sistemi sulla stessa  rete

locale  (esso  e' 254 perche' 0 e 255 non sono  consentiti  per

ragioni  che  saranno  discusse piu'  avanti).  Da  notare  che

128.6.4.194  e 128.6.5.194. sono sistemi distinti. Comunque  la

struttura  di  un indirizzo Internet e' descritta  meglio  piu'

oltre.

   Normalmente   si   fa   riferimento  a   certi   calcolatori

attraverso  dei nomi piuttosto che a degli indirizzi  Internet.

Quando si specifica un nome, il software di rete lo cerca in un

database e ritorna con un corrispondente indirizzo Internet. La

maggior  parte del software di rete tratta solamente  indirizzi

di  rete Internet (RFC 882 descrive la tecnologia del server di

nomi usato per gestire tutto cio').

   TCP/IP  e'  costruito con una tecnologia senza  connessioni:

l'informazione viene trasferita come una sequenza di datagrammi

che  sono  un insieme di dati da spedire come fosse un  singolo

messaggio.   Ognuno   di  questi  datagrammi  viene   trasmesso

attraverso la rete individualmente.

   Naturalmente  ci  sono  degli  accorgimenti  per  aprire  le

connessioni,  per  esempio:  iniziare  una  comunicazione   che

continuera'  per  un po' di tempo. Comunque  a  certi   livelli

l'informazione viene spezzata in datagrammi,  e questi  saranno

trattati dalla rete come se fossero completamente separati.

   Per  esempio,  si supponga di voler trasferire  un  file  di

15000  ottetti (15 Kb). Molte reti non gestiscono 15000 ottetti

in  datagrammi, percio' i protocolli li spezzeranno in qualcosa

come  30 datagrammi da 500 ottetti. Ognuno di questi datagrammi

sara'  inviato  poi  dall' altra parte. A  quel  punto  saranno

rimessi  insieme  nello stesso file da 15000 ottetti.  Comunque

mentre questi datagrammi sono in transito, la rete non sa'  che

esiste  una connessione tra di loro. E' perfettamente possibile

che  il datagramma 14 arrivi prima del datagramma 13. E'  anche

possibile che da qualche parte della rete capiti  un errore  ed

alcuni  datagrammi  non  arrivino  affatto.  In  quel  caso  il

datagramma deve essere rinviato .

   Da  notare,  in  proposito,  che  i  termini  datagramma   e

pacchetto   spesso   sembrano  essere  molto   intercambiabili.

Tecnicamente, datagramma e' la giusta parola da usare quando si

descrive  TCP/IP. Un datagramma e'  l' unita'  di  dati  che  i

protocolli  trattano.  Un pacchetto  e'  una  cosa  fisica  che

compare  su  Ethernet o via cavo, cioe' sul  mezzo  fisico.  In

molti  casi  il pacchetto contiene semplicemente un datagramma,

percio' c'e' molta poca differenza.

   In  ogni  caso  essi possono differire. Quando TCP/IP  viene

usato  su  rete  dati  X.25, la relativa interfaccia  spezza  i

datagrammi in pacchetti da 128 byte. Questo e' invisibile  allo

strato  IP, perche' i pacchetti vengono rimessi insieme  in  un

singolo  datagramma all'altro capo prima di  essere  processati

dal  TCP/IP.  Cosi' in questo caso, un datagramma  IP  verrebbe

trasportato da molti pacchetti. Tuttavia con la maggiore  parte

dei mezzi fisici, ci sono vantaggi in efficienza ad inviare  un

datagramma  per  pacchetto,  e cosi'  la  distinzione  tende  a

sparire .

   2.1 Il livello TCP

   Nella  gestione dei datagrammi TCP/IP vengono coinvolti  due

protocolli separati.

   TCP  (Transmision  Control Protocol) e'  responsabile  della

divisione   del   messaggio   in  datagrammi,   riassemblandoli

all'altro  capo, rinviando qualsiasi cosa che andasse  persa  e

rimettendo  le cose a posto nello stesso ordine.  IP  (Internet

Protocol)  e' responsabile dell' instradamento individuale  dei

datagrammi. Potrebbe sembrare che TCP faccia tutto il lavoro  e

in piccole reti questo e' vero.

   Comunque  sulla  rete  Internet  spedire  semplicemente   un

datagramma potrebbe essere un lavoro complesso. Una connessione

potrebbe  richiedere al datagramma di attraversare molte  reti.

Per esempio a Rutgers, dovrebbe attraversare: una linea seriale

al  Centro Supercomputer John von Neuman, li' una coppia di LAN

ethernet, una serie di linee telefoniche da 56 Kbaud all' altro

sito  NSFNet,  e  infine delle LAN ethernet sull'  altro  lato.

Tenere  traccia  delle  rotte di tutte  queste  destinazioni  e

gestire   le  incompatibilita'  tra  i  differenti   mezzi   di

trasporto, diventa un lavoro complesso.

   Da  notare  che  l'interfaccia tra  TCP e IP  e'  abbastanza

semplice. Infatti TCP passa semplicemente ad IP un datagramma e

una  destinazione. IP non sa come questo datagramma si  collega

ad uno precedente o successivo.

   A  questo punto puo' accadere che qualcosa vada perso. Si e'

parlato  di indirizzi Internet, ma non di come si tiene traccia

delle  connessioni multiple verso un dato sistema:  non  vi  e'

ancora chiaro abbastanza come inviare un datagramma alla giusta

destinazione.

   TCP   deve   sapere  a  quale  connessione   il   datagramma

appartiene.   Questo  compito  e'  chiamato   "Demultiplexing".

Infatti  ci sono molti livelli di demultiplexing che girano  su

TCP/IP.

   Le   informazioni  necessarie  a  fare  tale  lavoro,   sono

contenute  in una serie di "intestazioni o testate o  headers".

Una  intestazione  consiste semplicemente in  alcuni  ulteriori

ottetti   attaccati  all'inizio  del  datagramma   da   qualche

protocollo  allo  scopo  di mantenerne la  traccia.  Assomiglia

molto  all'operazione di mettere una lettera in  una  busta  ed

apporre su di questa l'indirizzo.

   Ad  eccezione delle moderne reti cio' accade molte volte. E'

come  se  si mettesse la lettera in una piccola busta,  poi  la

segretaria  la mette in una busta piu' grande, poi  l'  ufficio

postale la mette in una busta piu' grande ancora, etc.

   Ecco  una  sintesi  delle intestazioni che  accompagnano  un

messaggio che passa attraverso una tipica rete TCP/IP:

   Iniziamo con una singola striscia di dati, diciamo  un  file

che si sta tentando di inviare a qualche altro calcolatore:

  ............................................................

   TCP  lo spezza in tratti piu' facili da trattare e per  fare

questo  TCP deve conoscere la grandezza del datagramma  che  la

rete  puo'  gestire. Infatti, i protocolli  TCP  ad  ogni  capo

dicono  quanto grande e' il datagramma che possono gestire,  ed

allora lo riducono in una misura piu' piccola.

  .....  .....  .....  .....  .....  .....  .....  ..... .....

   TCP  mette  una intestazione all'inizio di ogni  datagramma.

Questa  testata infatti contiene almeno 20 ottetti,  ma  quelli

piu'  importanti sono "il numero di porta logica o  socket"  di

partenza e di arrivo e "il numero di sequenza".

   I  numeri  di  porte vengono usati per tener  traccia  delle

diverse conversazioni.

   Si  immagini  tre differenti persone che stanno  trasferendo

files. Il programma TCP puo' allocare a questi trasferimenti  i

numeri di porta per esempio: 1000, 1001,  1002. Quando si  sta'

mandando  un  datagramma,  essi diventano  i  numeri  di  porta

"sorgente  o  source", poiche' sono l'origine  del  datagramma.

Naturalmente, per la conversazione, il programma TCP  all'altro

capo  deve  assegnare il numero di porta propria  che  comunque

deve  divenire noto al corrispondente alla stessa maniera (esso

lo  scopre  quando la connessione inizia, come verra'  spiegato

piu'   sotto).   Questa   informazione  viene   immessa   nella

intestazione  e precisamente nel campo "porta di destinazione".

Ovviamente,  se l'altro capo rinvia un datagramma indietro,  le

porte  sorgente  e destinazione verranno rovesciate,  e  allora

saranno invertite la sorgente con la destinazione.

   Ogni  datagramma ha un numero di sequenza per far  si'  che,

l'altro capo possa assicurare un invio di datagrammi nel giusto

ordine,  e  che non se ne perda alcuno (si vedano le specifiche

TCP  per  i  dettagli). TCP non numera  i  datagrammi,  ma  gli

ottetti.  Cosi'  se  ci  sono  500  ottetti  di  dati  in  ogni

datagramma,  il  primo  successivo puo' essere numerato  0,  il

secondo  500,  il  successivo 1000, il successivo ancora  1500,

etc.

   Finalmente,  ecco   menzionata  la  "Somma  di  controllo  o

Checksum". Essa e' un numero che viene calcolato sommando tutti

gli  ottetti  nel  datagramma (piu'  o  meno  -  si  vedano  le

specifiche  TCP). Il risultato viene messo nella  intestazione.

TCP  dall'altro  capo calcola il Checksum di nuovo.  Se  questi

sono diversi, allora qualcosa e' capitato al datagramma durante

la spedizione percio' viene gettato via.

   Cosi' ecco come il datagramma appare adesso.

           =============================================

           |   Porta Sorgente   |   Porta Destinazione |

           =============================================

           |           Numero di Sequenza              |

           =============================================

           |           Numero di Ricevuta              |

           =============================================

           |offset o |          |U|A|P|R|S|F|          |

           |locazione|Riservato |R|C|S|S|Y|I| Finestra |

           |dei Dati |          |G|K|H|T|N|N|          |

           =============================================

           |Somma di controllo o Checksum|Punt. Urgente|

           =============================================

           |  ....... .......   dati  per i successivi |

           |            500 ottetti                    |

           |           ....... .......                 |

      Se  si  abbrevia la testata TCP con " T ", l'intero  file

appare come :

      T....  T....  T....  T....  T....  T....  T....  T....

   Si  notera' che ci sono diversi argomenti nell' intestazione

che  non  sono stati descritti prima. Questi generalmente  sono

implicati nella gestione della connessione.

   Allo  scopo di assicurare che il datagramma arrivi alla  sua

destinazione,  il  destinatario  deve  inviare   indietro   una

"ricevuta  o acknowledgement". Percio' viene immesso un  valore

nel  campo  "numero  di ricevuta" del datagramma.  Per  esempio

inviare  un pacchetto con una ricevuta di 1500 indica che  sono

stati ricevuti tutti i dati fino all'ottetto numero 1500. Se il

mittente  non  ottiene  ricevuta entro  un  tempo  ragionevole,

rinvia i dati di nuovo.

   Il  campo  "finestra"  viene  usato per  controllare  quanti

dati  possono  essere in transito ogni volta.  Non  e'  pratico

aspettare che ogni datagramma venga confermato prima di inviare

il  successivo: rallenterebbe troppo le cose. Dall'altra parte,

non si puo' sostenere continuamente l'invio di dati, altrimenti

un  calcolatore piu' veloce potrebbe sopraffare le capacita' di

uno  piu'  lento nell'assorbire dati. In questo modo ogni  lato

della  comunicazione indica quanti nuovi dati e' effettivamente

preparato  ad  assorbire mettendo il numero degli  ottetti  nel

proprio  campo  "finestra". Man mano che un calcolatore  riceve

dati,  la  quantita' di spazio rimasto nella  propria  finestra

diminuisce  e  quando  questa  va  a  zero,  il  mittente  deve

fermarsi. Via via che il destinatario processa i dati,  aumenta

la  propria  finestra,  indicando che e' pronto  ad  accettarne

degli altri. Spesso lo stesso datagramma puo' essere usato  per

dare  ricevuta di un gruppo di dati e dare il permesso di invio

per altri nuovi (aumentando la finestra).

   Il  campo  "urgente" permette ad un capo della comunicazione

di  dire  all'altro di saltare avanti e processare  particolari

ottetti.  Questo  spesso  e' utile  nella  gestione  di  eventi

asincroni, per es. quando si batte un carattere di controllo  o

altri  comandi  che  interrompono  l'output.  Gli  altri  campi

presenti  nel  datagramma TCP vanno oltre lo  scopo  di  questo

documento.

   2.2 Il livello IP

   TCP  invia  ognuno  di  questi datagrammi  ad  IP  indicando

l'indirizzo  Internet  del calcolatore all'  altro  capo  della

comunicazione. Da notare che questa e' l'unica informazione che

interessa  ad  IP.  Non deve preoccuparsi invece  di  cio'  che

contiene il datagramma o anche la testata di TCP.

   Il  lavoro  di IP e' semplicemente trovare una  rotta  sulla

rete per il datagramma ed inviarlo  dall'altra parte.

   Allo  scopo  di  permettere ai gateways o  routers  o  altri

sistemi intermediari di inoltrare il datagramma, IP aggiunge la

propria testata. Gli elementi principali in quest'ultima  sono:

l'indirizzo  sorgente e destinazione Internet (indirizzi  a  32

bit,  nella forma 128.6.4.194), il numero di protocollo,  e  un

altro checksum.

     L'indirizzo  Internet  sorgente  e'  semplicemente  quello

della  macchina  che  ha  originato la comunicazione  (cio'  e'

necessario in modo che il corrispondente conosca la provenienza

del datagramma).

   L'indirizzo  Internet  destinazione  e'  l'indirizzo   della

macchina all'altro capo della comunicazione (cio' e' necessario

in  modo  che qualsiasi gateway o router coinvolto  conosca  la

destinazione del datagramma generato).

   Il  numero  di  protocollo indica ad IP  all'altro  capo  di

inviare  il datagramma a TCP. Sebbene molto traffico  IP  venga

generato da TCP, ci sono altri protocolli che possono  usare  i

servizi di IP e percio' quest'ultimo deve sapere a quale strato

di protocollo inviare il datagramma.

   Finalmente,  il  checksum permette ad IP all'altro  capo  di

verificare  che  la  testata  non  sia  stata  danneggiata   in

transito.  Da notare che TCP e IP hanno separati checksums.  IP

deve  essere  in  grado di verificare che la  testata  non  sia

andata danneggiata in transito, altrimenti potrebbe inviare  un

messaggio al posto sbagliato. Per ragioni che esulano da questa

discussione,  e' piu' efficiente e sicuro che  TCP  calcoli  un

separato checksum per la testata TCP e i dati.

   Una  volta  che  IP ha realizzato la propria  testata,  ecco

come il messaggio apparira':

          =============================================

          |Version|IHL|Tipo di Servizio|Lunghezza tot |

          =============================================

          |Identificazione|Flags|Locazione del frammen|

          =============================================

          |Tempo di vita|Protocollo|Somma di controllo|

          |   T T L     |           dell'intestazione |

          =============================================

          |            Indirizzo di Sorgente          |

          =============================================

          |          Indirizzo di Destinazione        |

          =============================================

          |      Testata TCP , e poi i dati ......    |

          |                                           |

   Se  si rappresenta la testata IP con una " I ",  il file ora

rassomigliera' a questo:

      IT....  IT....  IT....  IT....  IT....  IT....  IT....

   Di  nuovo, la testata contiene alcuni campi addizzionali non

menzionati.  Molti  di  loro vanno oltre  lo  scopo  di  questo

documento.

   I  "Flags" e "La locazione dei frammenti o Fragment  Offset"

vengono   usati  per  tenere  traccia   dei  pezzi  quando   un

datagramma deve essere diviso. Questo  puo' accadere  quando  i

datagrammi  vengono inviati attraverso una rete  per  la  quale

questi sono troppo grandi (cio' sara' discusso fra breve).

   Il  "Tempo di Vita o Time to Live" e' un numero che decresce

ogni  volta  che un datagramma passa attraverso un  sistema  di

calcolo:  quando va' a zero il datagramma viene scartato.  Esso

e'  stato  creato  nel  caso che si sviluppi  nel  sistema  una

"chiusura su stesso o loop" in qualche modo. Naturalmente  cio'

non  dovrebbe mai accadere: infatti le reti ben progettate sono

costruite per affrontare condizioni impossibili.

   A  questo  punto, e' possibile che non siano piu' necessarie

altre  intestazioni.  Se il calcolatore dispone  di  una  linea

telefonica direttamente allacciata al corrispondente, o  ad  un

gateway,  puo' semplicemente inviare i datagrammi  sulla  linea

(e'  probabile che venga impiegato un protocollo sincrono  come

HDLC , e che questo aggiunga almeno alcuni ottetti all'inizio e

alla fine).

   2.3 Il livello Ethernet

   Molte  reti  locali (LAN) oggi usano la tecnologia  Ethernet

pertanto ora si rende necessario descriverne le intestazioni.

   Sfortunatamente  Ethernet ha i propri  indirizzi.  Chi  l'ha

progettata ha voluto assicurare che nessuna macchina terminasse

con  lo  stesso  indirizzo  Ethernet ed  inoltre  che  l'utente

dovesse  eventualmente preoccuparsi di assegnarli.  Cosi'  ogni

scheda (controller) Ethernet perviene dal fabbrica costruttrice

con un indirizzo entro contenuto non sostituibile.

   Allo   scopo   di   assicurare  che  non  si   debbano   mai

riutilizzare  gli  indirizzi,  i  progettisti  Ethernet   hanno

allocato 48 bits per tale indirizzo. I costruttori di schede di

rete  devono  registrare gli indirizzi utilizzati all'autorita'

centrale  per  assicurare  che  i  numeri  assegnati   non   si

sovrappongano a quelli di altri fabbricanti.

   Ethernet  e'  un  mezzo trasmissivo:  essa  si  comporta  in

effetti  come una vecchia linea telefonica. Quando si invia  un

pacchetto  su  Ethernet,  ogni  macchina  sulla  rete  vede  il

pacchetto, percio' e' necessario un meccanismo che assicuri  la

ricezione da parte della giusta macchina. Come si puo' intuire,

questo implica una nuova intestazione: quella Ethernet.

   Ogni  pacchetto Ethernet ha una intestazione composta da  14

ottetti  che  include  l'indirizzo della  macchina  sorgente  e

destinazione,  ed il tipo di codice. Ogni macchina  si  suppone

che  presti  attenzione ai pacchetti con il  proprio  indirizzo

Ethernet  nel  campo destinazione (tra l'altro e' perfettamente

possibile imbrogliare, ed e' questa una delle ragioni  per  cui

le comunicazioni Ethernet non sono terribilmente sicure).

   Da  notare che non c'e' connessione tra l'indirizzo Ethernet

e  l'indirizzo Internet. Ogni macchina deve avere  una  tabella

delle  corrispondenze tra l'indirizzo Ethernet e  Internet  (si

descrivera' fra poco come questa tabella viene costruita).

   In  aggiunta agli indirizzi la testata contiene un codice di

tipo.  Il  codice  tipo  esiste  per  consentire  a  differenti

famiglie  di  protocolli di essere impiegate sulla stessa  rete

fisica. In questo modo si potranno usare TCP/IP, DECnet,  Xerox

NS,  etc.  allo  stesso  tempo.  Ognuno  di  loro  mettera'  un

differente valore nel campo tipo.

   Ecco  finalmente il checksum. La scheda Ethernet calcola  un

checksum dell'intero pacchetto e getta via il pacchetto  se  la

risposta discosta dall' originale. Il checksum viene messo alla

fine del pacchetto e non nella testata.

   Il risultato finale assomiglia a questo:

         ====================================================

         |Indirizzo di destinazione Ethernet ( primi 32 bit)|

         ====================================================

         |  Destinazione Ethernet |  Sorgente  Ethernet     |

         |    (ultimi 16 bit)     |   (primi 16 bits)       |

         ====================================================

         |Indirizzo Sorgente Ethernet (gli ultimi 32 bits ) |

         ====================================================

         |  Tipo di codice        |                         |

         ====================================================

         | Testata IP , poi Testata TCP, poi i dati ......  |

         |           ..... ..... .....                      |

         |                  Fine dei dati                   |

         ====================================================

         |                Checksum Ethernet                 |

         ====================================================

   Se  si  rappresenta  la  testata  Ethernet  con  "E",  e  il

checksum  Ethernet  con "C", l'iniziale invio  di  file  adesso

appare cosi:

    EIT....C  EIT....C  EIT....C  EIT....C  EIT....C  EIT....C

   Naturalmente, quando questi pacchetti saranno  ricevuti  dal

corrispondente, tutte le testate saranno rimosse.

   Percio'  l'interfaccia Ethernet rimuove la  propria  testata

ed  il proprio checksum; inoltre osserva il "tipo di codice"  e

se  esso  e'  stato assegnato ad IP. In tal caso il dispositivo

software che pilota la scheda Ethernet, cioe' il device driver,

passa  il datagramma su' allo strato IP che rimuove la relativa

testata  osservando  il  campo protocollo  di  IP.  Poiche'  il

"protocollo  tipo"  indica TCP, passa il  datagramma  su'  allo

strato  TCP.  A  sua volta TCP osserva il numero  di  sequenza.

Quest'ultimo   ed  altre  informazioni,  verranno   usate   per

combinare tutti i datagrammi nel file originale.

   Qui   termina  l'iniziale  sommario  su  TCP/IP.  Ci   sono,

tuttavia   ancora diversi concetti cruciali che non sono  stati

toccati,   percio'  ora  si  tornera'  indietro  ad  aggiungere

dettagli in diverse aree della trattazione.

   Per  descrizioni  dettagliate di argomenti discussi  qui  si

vedano  le RFC 793 per TCP,  RFC 791 per IP, RFC 894 e 826  per

l'invio di IP su Ethernet.

   3. Porte o Sockets e Strati  applicativi

   Fin  qui,  e' stato descritto come un flusso di  dati  viene

spezzato  in  datagrammi, inviato ad  un  altro  calcolatore  e

rimesso  insieme. Tuttavia e' necessario qualcosa di  piu'  per

realizzare una comunicazione utile.

   Cioe'  ci   deve  essere  la  possibilita'  di  aprire   una

connessione   con   uno   specifico   calcolatore,   accedervi,

indicargli  quale file si desidera ricevere e  controllarne  la

sua trasmissione.

   Puo'  venire in mente una applicazione diversa da FTP,  come

l'invio  di posta su calcolatore: ebbene e' necessario  qualche

protocollo analogo.

   Le   operazioni  appena  descritte  vengono  effettuate  dai

"protocolli applicativi". Essi operano sopra i livelli di TCP e

IP.   Cioe',   quando  gli  applicativi  vogliono  inviare   un

messaggio,  lo  danno  a  TCP  che  assicura  la  recapitazione

all'altro  capo  della  comunicazione.  Poiche'  TCP  e  IP  si

prendono  cura  di  tutti  dettagli della  rete,  i  protocolli

applicativi  possono trattare una connessione di rete  come  se

fosse  un  semplice flusso di bytes, paragonabile  a  cio'  che

accade su un terminale o una linea telefonica.

   Prima    di   addentrarsi   nei   dettagli   sui   programmi

applicativi,   e'   necessario  descrivere  come   trovare   un

applicazione.

   Si  supponga di voler inviare un file ad un calcolatore  con

l'indirizzo  Internet  "128.6.4.7". Per iniziare  il  processo,

esso   non   e'  sufficiente:  bisogna  effettuare  prima   una

connessione logica al server FTP all'altro capo. Generalmente,

   gli  applicativi di rete  sono  specializzati

per  uno specifico insieme di compiti. Molti sistemi di calcolo

hanno  programmi  separati che gestiscono trasferimento  files,

accesso remoto di terminali, posta elettronica, etc.

      Quando   ci  si  connette,  per  esempio,  alla  macchina

"128.6.4.7",  bisogna specificare che si vuole parlare  con  il

server  FTP.  Cio' si ottiene conoscendo le "porte riservate  o

sockets"  per ogni server. Da ricordare che TCP usa  numeri  di

porta  per  tenere  traccia delle conversazioni  individuali  e

pertanto  i  programmi di utenza o client, usano  piu'  o  meno

numeri  di  porta  casuali. Mentre specifici  numeri  di  porta

vengono  riservati ai programmi che sono in attesa di richieste

o server.

   Per  esempio  se  si vuole inviare un file, si  avviera'  un

programma  che  si  chiama  FTP. Esso aprira'  una  connessione

usando  per  se' alcuni numeri di porta casuali  come:  "1234".

Mentre  specifichera'  la porta numero  21  per  l'altro  capo:

questa e' la porta ufficiale riservata al server FTP.

   Da  notare  che ci sono due differenti programmi  coinvolti.

Da  una  parte  e' attivo il cliente FTP: esso e' il  programma

appositamente  creato  per  accettare  comandi  dal  terminale,

quindi dall'umano, per poi passarli all'altro capo. Dall'altra,

invece,  si  interagisce con il programma FTP  server,  che  si

trova   appunto   sulla   macchina  remota:   esso   e'   stato

appositamente  creato per accettare comandi da  connessioni  di

rete piuttosto che da terminali interattivi.

   Non  c'e'  necessita' per il programma cliente di  usare  un

numero di "porta riservato" (nell'esempio e' il numero 21)  per

se':  nessuno  lo sta' cercando. Al contrario i servers  devono

averlo, in modo che la gente possa aprire connessioni verso  di

questi e iniziare ad inviare i comandi.

   I  numeri ufficiali delle porte riservate per ogni programma

sono riassunte nel documento "Numeri Assegnati".

   Da  notare  che una connessione e' effettivamente  descritta

da un insieme di 4 numeri: l'indirizzo Internet ad ogni capo, e

il numero di porta TCP ad ogni capo.

   Ogni   datagramma   ha   tutte  e  quattro   questi   numeri

all'interno (gli indirizzi Internet sono nella testata IP, e  i

numeri  di  porta TCP sono nella testata TCP).  Allo  scopo  di

tenere   le  cose  in  ordine,  non  ci  potranno  essere   due

connessioni  che  hanno  lo  stesso  insieme  di   numeri:   e'

sufficiente essere differente di un'unita.

   Per  esempio, e' perfettamente possibile per due  differenti

utenti   sulla  stessa  macchina  inviarsi  dei  files.  Questo

potrebbe risultare in connessione con i seguenti parametri:

                          TCP             TCP

    Indirizzi Internet:   locale          remoto     Porte

       connessione 1      128.6.4.194,    128.6.4.7  1234, 21

       connessione 2      128.6.4.194,    128.6.4.7  1235, 21

   Poiche'  sono  coinvolte la stesse macchine,  gli  indirizzi

Internet  sono gli stessi e siccome stanno entrambi effettuando

un  trasferimento di files, un capo della connessione occupa la

porta riservata del server FTP. La sola cosa che differisce  e'

il  numero della porta che sta' usando per il programma utente.

Questo naturalmente fa la differenza.

   Generalmente,  almeno un capo della connessione,  chiede  al

software  di  rete di assegnargli un numero di  porta  che  sia

garantito di essere unico. Normalmente accade dal lato utente o

cliente, poiche' il server deve usare un numero riservato.

   Adesso  che  si  conosce il modo di aprire  connessioni,  si

tornera' indietro ai programmi applicativi.

   Come  menzionato  prima, una volta che  TCP  ha  aperto  una

connessione, si avra' qualcosa che potrebbe assomigliare ad  un

semplice  cavo o linea. Tutte le parti fisiche vengono  gestite

da  TCP e IP. Tuttavia e' necessario ancora qualche accordo su:

cosa inviare sulla connessione. In effetti questo e' un accordo

su  quali  insiemi  di comandi l'applicazione  capira',  ed  il

formato  che  dovra' essere usato per l'invio. Generalmente  si

tratta  di una combinazione di comandi e dati inviati  in  modo

contestuale.

   Per  esempio,  il  protocollo  per  la  posta  lavora  cosi:

l'applicativo di posta apre una connessione al server  apposito

all'altro  capo,  gli  comunica il  nome  della   macchina,  il

mittente  del messaggio, ed il destinatario al quale  si  vuole

effettuare la relativa spedizione. Poi invia un comando dicendo

che   il   messaggio  sta  per  partire.  A  quel   punto,   il

corrispondente, smette di trattare come comandi cio'  che  vede

arrivare sulla connessione ed inizia ad accettare il testo vero

e  proprio del messaggio. Terminato la trasmissione di  questo,

viene  inviato un segno speciale: un punto nella prima colonna.

Dopo  di cio', entrambi i lati, client e server, capiranno  che

il  programma sta di nuovo inviando comandi. Questa e' il  modo

piu' semplice ed anche quello che molte applicazioni usano.

   Il  trasferimento di files e' qualcosa di piu' complesso. Il

protocollo per il trasferimento di files implica due differenti

connessioni. Inizia in modo analogo alla posta.

   Il  programma utente invia comandi tipo: "Fammi entrare come

Questo  Utente", "Questa e' la mia parola chiave", "Inviami  il

file  con  Questo  Nome". Comunque una  volta  che  il  comando

d'invio  dei  dati  viene trasmesso, viene aperta  una  seconda

connessione per i soli dati. Sarebbe certamente possibile, come

fa  la  posta, inviare i dati nella stessa connessione, sebbene

il   trasferimento  di  files  spesso  impieghi  tempi  lunghi.

Tuttavia  i  progettisti  di  questo  protocollo  hanno  voluto

concedere all'utente di continuare ad inviare comandi mentre il

trasferimento e' in atto. Per esempio, l'utente puo'  fare  una

ricerca,  o puo' abbattere il trasferimento. In questo  modo  i

progettisti   hanno  sentito  che  fosse   meglio   usare   una

connessione  separata  per  i dati e  lasciare  la  connessione

originale per i comandi.

   E'  anche  possibile aprire connessioni per  comandi  a  due

differenti  calcolatori e dire loro di inviarsi  i  files  l'un

l'altro.  In  quel  caso,  i dati non possono  attraversare  la

connessione per i comandi.

   Le   connessioni   di  terminali  remoti  usano   un   altro

meccanismo  ancora. Per questa operazione c'e' una  connessione

che  normalmente  invia  dati.  Quando  e'  necessario  inviare

comandi,  per  esempio per comunicare il tipo  di  terminale  o

cambiare  alcuni  modi  di  lavoro, viene  usato  un  carattere

speciale.  Se  all'utente  capita di  digitare  quel  carattere

speciale come dati, ne saranno inviati due.

   Non   c'e'   l'intenzione   di  descrivere   il   protocollo

applicativo  nei  dettagli in questo  documento:  sara'  meglio

leggersi le RFC appropriate da soli.

   Tuttavia ci sono un paio di convenzioni comuni  usate  dalle

applicazioni che saranno qui descritte.

   Primo,  la  rappresentazione comune in rete:  TCP/IP  e'  da

intendere  usabile  su  ogni calcolatore. Sfortunatamente,  non

tutti   i  calcolatori vanno d'accordo su come rappresentare  i

dati.  Ci  sono  differenze di codici nei  caratteri,  ASCII

EBCDIC,  nelle  convenzioni di fine linea , Carriage  Return

Line  Feed,  o  rappresentazioni  che  usano  numeri,  e  se  i

terminali si aspettano caratteri da inviarsi individualmente  o

una linea alla volta.

   Allo  scopo   di permettere a calcolatori di tipo differente

di   comunicare,  ogni  protocollo  applicativo  definisce  una

rappresentazione standard.

   Da   notare   che   TCP   e   IP   non   si   curano   della

rappresentazione. TCP invia semplicemente ottetti.

   Comunque   i  programmi  agli  estremi  della  comunicazione

devono  andare d'accordo su come gli ottetti stanno per  essere

rappresentati   infatti  l'RFC  specifica  la  rappresentazione

standard   per  ogni  applicazione. Normalmente  essa  e'  "net

ASCII".  Questa usa caratteri ASCII, con il carattere  di  fine

riga  composto  da  un "Carriage Return" seguito  da  un  "Line

Feed". Per l'accesso remoto, esiste anche una definizione di un

terminale  standard, che si presenta in modo  "semiduplice  con

l'eco sulla macchina locale".

   Molte  applicazioni  danno  anche  la  possibilita'  a   due

calcolatori  di andare d'accordo su altre rappresentazioni  che

possono trovare piu' convenienti. Per esempio, il Digital  PDP10

ha  parole di  bit da 36: c'e' modo, infatti, di far andare

d'accordo due PDP-10 per l'invio di files binari a 36-bit. Alla

stessa  maniera, due sistemi che preferiscono conversazioni  di

terminali in duplice possono andare d'accordo.

   Comunque   ogni   applicazione   ha   una   rappresentazione

standard, la quale ogni macchina deve supportare.

   3.1 Un esempio di applicazione: SMTP

   Per  dare un'idea migliore di cio' che trattano i protocolli

applicativi, sara' mostrato un esempio di connessione SMTP, che

e'  il  protocollo per la posta elettronica  (  SMTP  sta'  per

"Simple Mail Transfer Protocol").

   Si  supponga  che  un utente presso il calcolatore  di  nome

TOPAZ.RUTGERS.EDU voglia inviare il seguente messaggio:

      Data: Sab, 27 giu 87 13:26:31

      Da:  hedrick@topaz.rutgers.edu

      A:  levy@red.rutgers.edu

      Oggetto: incontro

                Incontriamoci Lunedi alle tredici.

   Primo:  da  notare che il formato del messaggio e' descritto

da  Internet Standard (RFC 822). Lo standard specifica  che  il

messaggio  deve essere trasmesso con la rappresentazione   "net

ASCII" (per esempio deve essere ASCII, con Carriage Return/Line

Feed  per  delimitare la linea). Descrive  anche  la  struttura

generale, che deve essere costituita da un gruppo di  linee  in

testa  e  poi  una  linea bianca che la separa  dal  corpo  del

messaggio.  Finalmente,  descrive la sintassi  delle  linee  di

testa  in  dettaglio. Generalmente queste consistono di  parole

chiave e poi valori numerici.

   Da   notare   che  l'indirizzo  e'  indicato   nella   forma

LEVY@RED.RUTGERS.EDU.

   Inizialmente,  gli  indirizzi erano  semplicemente  "persona

presso la macchina (persona@la_macchina)", poi recenti standard

hanno reso le cose piu' flessibili.

     Ci  sono ora accorgimenti per la gestione di altri sistemi

di posta elettronica. Infatti e' possibile l'inoltro automatico

della  posta per conto di calcolatori non connessi all'Internet

(si  veda  il  protocollo  POP). Come pure  dirigere  la  posta

destinata  ad  un  certo  numero di  sistemi  verso  un  server

centrale  .  Di certo non c'e' l'esigenza che esista  un  reale

calcolatore con il nome  RED.RUTGERS.EDU. I servers dei nomi si

possono  installare  in maniera tale che si  possa  inviare  la

posta  verso  i nomi di dipartimento affinche' venga  dirottata

automaticamente al calcolatore appropriato. E' anche  possibile

che  la parte a sinistra del simbolo @ (che vuol dire "presso")

sia qualcos'altro che il nome d'utenza.

   E'  inoltre possibile che i programmi vengano installati per

processare  la  posta, gestire liste postali, e  nomi  generici

come "direttore" o "operatore".

   Il  modo  in cui il messaggio sta per essere inviato  ad  un

altro sistema di calcolo, e' descritto nella RFC 821 e 974. Il

   programma  che  sta per effettuare  l'invio,  chiede  al

server   dei  nomi  molte  indicazioni  per  determinare   dove

dirottare  il  messaggio. La prima domanda serve  per  scoprire

quale  macchina  gestisce  la posta  per  il  sistema  di  nome

RED.RUTGERS.EDU  nell'esempio.  In  questo  caso,   il   server

risponde  che  RED.RUTGERS.EDU gestisce da  se'  la  posta.  Il

client  allora chiede l'indirizzo IP di RED.RUTGERS.EDU che  e'

"128.6.4.2". Una volta ottenuto, esso  apre una connessione TCP

sulla  porta 25 presso il sistema "128.6.4.2". La porta  25  e'

riservata  e viene usata per ricevere posta. Una volta  che  la

connessione  viene effettuata, il programma inizia  ad  inviare

comandi.

   Ecco  una tipica conversazione. Ogni linea e' contrassegnata

come  se fosse proveniente da TOPAZ o RED. Da notare che  TOPAZ

ha iniziato la connessione:

  RED   220 RED.RUTGERS.EDU SMTP Service at 29  jun 87 05:17:18

TOPAZ     HELO topaz.rutges.edu

  RED   250 RED.RUTGERS.EDU - Hello,TOPAZ.RUTGERS.EDU

TOPAZ     POSTA Da:<hedrick@topaz.rutgers.edu>

  RED   250 Posta accettata

TOPAZ     RCPT  To: <levy@red.rutgers.edu>

  RED   250 Destinatario accettato

TOPAZ     DATA

  RED   354 Comincia ad immettere il testo; termina con i

            caratteri <CRLF>.<CRLF>

TOPAZ     Date : Sat, 27 Jun 87 13:26:31

TOPAZ     Da: hedrick@topaz.rutgers.edu

TOPAZ     A: levy@red.rutgers.edu

TOPAZ     Oggetto: incontro

TOPAZ

TOPAZ     Incontriamoci lunedi alle 13.00.

TOPAZ     .

  RED          250 OK

TOPAZ     QUIT

  RED     221 RED.RUTGERS.EDU Chiusura del canale di

          trasmissione in servizio

   Primo:  da  notare che tutti i comandi usano  testo  normale

che  e'  tipico  dello standard Internet. Molti dei  protocolli

usano   comandi  ASCII  standard  che  rendono  piu'   semplice

l'osservazione  di  cio' che sta succedendo e  degli  eventuali

problemi.

   Per  esempio, il programma della posta prende nota  di  ogni

conversazione e se qualcosa va storta, il  file  di  note  puo'

semplicemente essere spedito al direttore.

   (Tuttavia  alcuni nuovi protocolli sono abbastanza complessi

che non rendono pratica questa operazione. I comandi dovrebbero

avere   una   sintassi   che  richiederebbe   un   analizzatore

consistente.   Per  questo c'e' la tendenza  di  usare  formati

binari   per  i  nuovi  protocolli.  Generalmente   essi   sono

realizzati come le strutture record in linguaggio C o Pascal).

   Secondo,  c'e' da notare che tutte la risposte iniziano  con

numeri.  Anche  questo  e' tipico dei protocolli  Internet.  Le

risposte  possibili  sono  definite nel  protocollo.  I  numeri

permettono  al programma utente di rispondere senza ambiguita'.

Il  resto  delle  risposte e' testo in  modo  da  consentire  a

qualunque umano di controllare il giornale delle note e  dunque

non ha effetto sulle operazioni dei programmi (comunque c'e  un

caso in cui il protocollo usa parte del testo delle risposte).

   I   comandi  permettono  semplicemente  al  programma  della

posta  presso  un sito, di comunicare al server le informazioni

necessarie  allo  scopo di consegnare il messaggio.  In  questo

caso,  il  server  della  posta puo' ottenere  le  informazioni

osservando  il  messaggio stesso. Ma per casi  piu'  complessi,

cio' non sarebbe sicuro.

   Ogni  sessione deve iniziare con HELO, che da' il  nome  del

sistema che ha iniziato la connessione. Poi vengono specificati

il  mittente  ed  il destinatario ( ci puo' essere  piu  di  un

comando RCPT, se ci sono piu destinatari)

   Finalmente  vengono inviati i soli dati. Da  notare  che  il

testo  del  messaggio viene terminato da una  linea  contenente

esattamente un periodo (se tale linea appare nel messaggio,  il

periodo  viene  raddoppiato).  Dopo  che  il  messaggio   viene

accettato,  il  mittente puo' inviare  un  altro  messaggio,  o

terminare la sessione come nell'esempio sopra.

   Generalmente, c'e' un modello per i numeri di  risposta.  Il

protocollo  definisce  un  insieme specifico  di  risposte  che

possono  essere  inviate  ad  ogni  comando  dato.  Comunque  i

programmi  che  non vogliono analizzarle nei dettagli,  possono

osservare solo la prima cifra.

   In  generale  le risposte che cominciano con il  numero  "2"

indicano successo. Quelle che iniziano con il "3" indicano  che

alcune azioni ulteriori sono richieste, come mostrato sopra. "4

e  5"  indicano  errori. "4" e' un errore  "temporaneo",   come

capita  per il riempimento del disco (il messaggio puo'  essere

salvato  per ritentare di nuovo piu' avanti). "5" e' un  errore

permanente,  come  succede  per  un  destinatario  inesistente:

quindi  la  posta dovrebbe tornare al mittente con un messaggio

d'errore.

   Per  maggiori  dettagli  vedere i protocolli  menzionati  in

questa  sezione:  RFC  821/822 per la posta,  RFC  959  per  il

trasferimento files, e RFC 854/855 per l'accesso remoto. Per le

porte riservate, vedere l'edizione corrente di Numeri Assegnati

e possibilmente RFC 814.

   4. Altri protocolli oltre TCP: UDP e ICMP

   Fin  qui, sono state descritte solo le connessioni che usano

TCP. Si ricorda che esso e' responsabile del frazionamento  dei

messaggi in datagrammi, e del loro corretto riassemblaggio.

   Comunque  molte applicazioni generano messaggi  che  saranno

adatti  per  un singolo datagramma, per esempio per la  ricerca

del  nome  dell'host. Quando un utente tenta di effettuare  una

connessione con un altro sistema, generalmente ne specifica  il

nome, piuttosto che l'indirizzo Internet; quindi il suo sistema

deve  tradurre  quel nome in un indirizzo IP prima  che  questo

possa  agire.  Generalmente  solo pochi  calcolatori  hanno  un

database per tradurre i nomi in indirizzi, pertanto gli  utenti

faranno una richiesta a loro. Tale richiesta sara' molto  breve

e  sicuramente  si adattera' in un datagramma e cosi'  pure  la

risposta.

   Per  questo compito sembra stupido usare il TCP perche' esso

fa  molto  di  piu' che spezzare il messaggio  e  metterlo  nei

datagrammi. TCP assicura anche che i dati arrivino, rinviandoli

dove  e' necessario. Ma per una richiesta che si adatta  in  un

singolo datagramma, non serve tutta la complessita' del TCP. Se

non  si  ottiene  risposta  dopo alcuni  secondi,  la  si  puo'

chiedere  di  nuovo.  Per applicazioni  come  questa,  ci  sono

alternative al TCP.

   L'alternativa   piu'   comune   e'   UDP   ("User   Datagram

Protocol"). UDP e' stato progettato per applicazioni  dove  non

e'  necessario  mettere  sequenze di datagrammi  insieme  e  si

adatta nel sistema in modo simile a TCP.

   C'e'  una  intestazione UDP che  il software di rete  genera

all'inizio dei dati, come se mettesse una testata TCP. Poi  UDP

invia  i  dati ad IP che aggiunge una propria testata inserendo

nel  campo  "tipo di protocollo" il numero di  codice  di  UDP,

anzicche' quello di TCP.

   Comunque  UDP non e' capace di fare il lavoro di  TCP:  esso

non divide i dati in datagrammi multipli, non tiene traccia  di

cio'  che  e' stato inviato cosi' che possa essere rinviato  se

necessario.

   UDP  fornisce  solo  le porte numerate, in  modo  che  molti

programmi possano utilizzarlo immediatamente. I numeri di porta

UDP  vengono  usati come quelli TCP. Ci sono  numeri  di  porta

riservati per i server e numeri di porte casuali per i client.

   Da  notare  che la testata UDP e' piu' corta di quella  TCP.

Essa  include  i numeri di porta sorgente, destinazione,  e  il

checksum,  ma  questo  e' tutto. Non compare  alcun  numero  di

sequenza, poiche' esso non e' necessario.

   UDP  viene  usato dai protocolli che gestiscono  la  ricerca

dei nomi, ed applicazioni simili.

   Un  altro protocollo alternativo e' ICMP ("Internet  Control

Message  Protocol").  ICMP  viene usato  per  inviare  messaggi

d'errore,  ed  altri  messaggi significativi  per  il  software

TCP/IP  stesso,  piuttosto  che  alcuni  particolari  programmi

d'utente.  Per esempio, se si tenta di connettere un  host,  il

sistema   puo'   ricevere  un  messaggio  ICMP  dicendo   "Host

Irraggiungibile (host unreachable)".

   ICMP  puo'  anche  essere  usato per  scoprire  informazioni

sulla rete (si veda RFC 792 per i dettagli).

   ICMP  e'  simile ad UDP nel fatto che gestisce messaggi  che

si  adattano in un datagramma. Tuttavia e' ancora piu' semplice

di UDP. Esso non ha le porte numerate nella sua testata poiche'

tutti i messaggi ICMP vengono interpretati dal software di rete

stesso.  Quindi  non e' necessario alcun numero  di  porta  per

comunicare dove sia diretto un messaggio ICMP.

   5.  Tenere  traccia  dei  nomi  e  delle  informazioni:  "Il

sistema Domain".

   Come  indicato  prima, il software di rete  generalmente  ha

bisogno  di  un  indirizzo Internet di 32 bit  per  aprire  una

connessione o inviare datagrammi. Pero' gli utenti preferiscono

trattare con dei nomi associati a calcolatori anzicche' numeri.

Percio'  esiste un database che permette al software di cercare

un nome e di trovare il corrispondente numero di rete.

   Quando  l'Internet  era  piccola,  cio'  era  facile.   Ogni

calcolatore  aveva  un file che elencava  tutto  su  gli  altri

sistemi,  assegnando loro un nome e un numero. Adesso  ci  sono

troppi   calcolatori  perche'  questo  approccio  sia  pratico.

Percio' questi files sono stati sostituiti da un gruppo di nomi

di  servers che tengono traccia dei nomi degli hosts e dei loro

indirizzi  Internet. Infatti questi servers sono piu'  generici

rispetto ai primi sistemi e questo e' solo un esempio sul  tipo

di informazione immagazzinata nel sistema Domain.

   Da   notare   che   viene  usato  un  insieme   di   servers

intercollegati piuttosto che uno singolo e centrale.

   Ci   sono   oggi   tante  differenti  istituzioni   connesse

all'Internet  e  non sarebbe pratico per loro  notificare  all'

autorita'   centrale  nuove  installazioni   o   rimozioni   di

calcolatori.  In  questo modo l'autorita' per la  gestione  dei

nomi viene delegata individualmente alle istituzioni. I servers

dei  nomi  formano  un  albero corrispondente   alla  struttura

istituzionale ed i nomi seguono una struttura simile.

   Un   esempio  tipico  e'  il  nome  BORAX.LCS.MIT.EDU.  Esso

rappresenta un calcolatore presso il Laboratorio per la Scienza

dei  Computer  presso  il MIT. Allo scopo  di  trovare  il  suo

indirizzo  Internet, si dovrebbero consultare quattro   servers

differenti. La prima richiesta sarebbe per il server  centrale,

chiamato  "di  radice o root", per scoprire dove  si  trova  il

server   EDU.  EDU  e'  un  server  che  tiene  traccia   delle

istituzione educazionali o universitarie. Il server  di  radice

darebbe i nomi e gli indirizzi Internet di parecchi servers per

EDU  (ci  sono   molti server ad ogni livello, che garantiscono

una  certa  continuita' anche nel caso  di  avaria  di  uno  di

questi). Poi si chiederebbe ad EDU dove si trova il server  per

MIT. Di nuovo  EDU  darebbe  i nomi e gli indirizzi Internet di

molti  servers per MIT. Normalmente,  nessuno di  quei  servers

dovrebbe  essere  presso il MIT, per evitare  che  ci  sia  una

interruzione del servizio dovuta, per esempio, ad una  generale

mancanza di energia elettrica. Poi ancora si chiederebbe a  MIT

dove si trova il server LCS, e finalmente si chiederebbe ad uno

dei  server  LCS  informazioni su BORAX.  Il  risultato  finale

darebbe  l'indirizzo Internet  di BORAX.LCS.MIT.EDU. Ognuno  di

questi livelli e' un "Dominio".

   Il  nome  intero:  BORAX.LCS.MIT.EDU, e' chiamato  "Nome  di

Dominio"  (cosi'  appaiono i nomi  dei  livelli   piu  alti  di

dominio come: LCS.MIT.EDU,  MIT.EDU e EDU).

   Fortunatamente,  non  e' realmente  necessario  attraversare

tutti questi sistemi di servers.

   Prima  di  tutto i servers dei nomi di radice sono  anche  i

servers dei nomi per i domini di livello piu' alto, cosi'  come

EDU.  In  questo  modo una singola richiesta ad  un  server  di

radice condurrebbe a MIT.

   Secondo,  il software generalmente ricorda le risposte  date

precedentemente.  Cosi'  una volta  che  si  cerca  il  nome  a

LCS.MIT.EDU, il software si ricorda dove trovare i servers  per

LCS.MIT.EDU, MIT.EDU, EDU, e si ricorda anche la traduzione  di

BORAX.LCS.MIT.EDU.

   Ognuno   di questi pezzi di informazione  ha un "  Tempo  di

Vita o Time To Live" ad esso associato. Tipicamente questo vale

alcuni  giorni. Dopo di cio' l'informazione cessa e deve essere

ricercata  di  nuovo.  Questo  permette  alle  istituzioni   di

cambiare le cose.

   Il  sistema  Domain non si limita a scoprire  gli  indirizzi

Internet. Ogni nome di dominio e' un nodo nel database. Il nodo

puo'  avere  delle voci che definiscono un numero di proprieta'

differenti. Un esempio sono "gli indirizzi Internet", "tipo  di

calcolatore"  e  "una  lista  di servizi  forniti  da  un  dato

calcolatore".  Un  programma puo' chiedere  delle  informazioni

specifiche, o tutto su un dato nome.

   E'   possibile per un nodo nel database essere  segnato  con

un  "soprannome o alias" per un altro nodo. E' anche  possibile

usare  il  sistema Domain per immagazzinare informazioni  sugli

liste di utenti di posta o altri oggetti.

   Esiste uno standard Internet che definisce le operazioni  su

questi  database  ed  i  protocolli  usati  per  effettuare  le

richieste appropriate.

   Ogni  utilita'  di rete deve essere in grado  di  fare  tali

richieste,  poiche'  questo e' adesso  il  modo  ufficiale  per

risolvere   i   nomi   di  hosts.  Generalmente   le   utilita'

converseranno  con un server sulla loro rete che  si  prendera'

cura di contattare gli altri servers per loro.

   Tutto  cio' riduce l'ammontare di codice macchina  che  deve

essere presente in ogni programma applicativo.

   Il  sistema  Domain  e' particolarmente  importante  per  la

gestione  della posta. Ci sono tipi di accessi che  definiscono

quale   calcolatore  gestisce  la  posta  per  un  dato   nome,

specificano  dove un individuo puo' riceverla,  e  attivano  le

liste di posta.

   (Si  vedano  le  RFC 882, 883, e 973 per le  spccifiche  del

sistema  Domain.  RFC 974 definisce l'uso  del  sistema  Domain

nell'invio della posta).

   6. Instradamento e Rotte

   La  descrizione data qui sopra spiega che IP e' responsabile

della  consegna  dei datagrammi verso la destinazione  indicata

sull'  indirizzo,  ma  poco e' stato  detto  su  come  cio'  si

realizza.

   Il  compito  di  scoprire  come portare  i  datagrammi  alla

propria  destinazione  e' chiamato "instradamento  o  routing".

Sebbene diversi dettagli dipendono da particolari realizzazioni

software, alcune concetti generali possono essere spiegati.

   Primo,  e'  necessario capire il modello  sul  quale  IP  e'

basato. Esso presume che un sistema di calcolo sia attaccato ad

alcune reti locali. Si suppone che il calcolatore possa inviare

datagrammi ad ogni altro sistema sulla propria rete locale. Per

esempio   nel  caso  di  Ethernet,  esso  scopre  semplicemente

l'indirizzo fisico Ethernet del sistema destinatario, ed emette

il  datagramma verso di questo. Il problema esiste quando viene

chiesto  ad  un  sistema  di  inviare  un  datagramma   ad   un

calcolatore  su una rete remota, o comunque differente.  Questo

problema viene gestito e risolto da un gateway o router IP.

   Un  gateway o router e' un sistema che connette una rete con

molte  altre reti e spesso e' costituito da normali calcolatori

che hanno piu' di una interfaccia rete.

     Per esempio, si abbia una macchina Unix con due differenti

interfacce  Ethernet.  In questo modo  essa  si  connette,  per

ipotesi,  alle  reti locali 128.6.4 e 128.6.3. Questa  macchina

puo'  agire  come gateway tra queste due reti  se  il  software

viene  installato  per  inoltrare  i  datagrammi  da  una  rete

all'altra.  Cioe',  se una macchina sulla rete  locale  128.6.4

invia  un datagramma al gateway, e lo indirizza ad una macchina

sulla  rete  locale 128.6.3, questo inoltrera'   il  datagramma

alla destinazione.

   I  maggiori  centri di comunicazione spesso  hanno  gateways

che connettono un numero di reti differenti.

   In  generale  comunque,  sistemi di  gateways  specializzati

forniscono prestazioni migliori o sono piu' affidabili di altri

calcolatori generici che agiscono come tale. Infatti oggi  sono

reperibili sul mercato diverse marche di tali sistemi  detti  a

punto router o gateway.

   Il  sistema  di instradamento IP e' basato completamente sul

numero di rete dell'indirizzo destinazione. Ogni calcolatore ha

installato  una tabella di numeri di rete e per  ogni   numero,

viene  indicato  un  gateway che viene  usato  per  raggiungere

quella  rete.  Da  notare che il gateway non  deve  connettersi

direttamente  alla  rete  di  destinazione:  esso   deve   solo

rappresentare il miglior posto per raggiungerla.

   Per  esempio a Rutgers, l'interfaccia verso NSFnet e' presso

il Centro Supercomputer John von Neuman (JvNC) e la connessione

per JvNC avviene attraverso una linea seriale ad alta velocita'

connessa ad un gateway con l'indirizzo 128.6.3.12 . Il  sistema

sulla rete 128.6.3 indichera' 128.6.3.12 come gateway per molte

reti  al  di fuori del campus universitario. Mentre il  sistema

sulla rete 128.6.4 indichera' 128.6.4.1 come gateway per quelle

stesse reti al di fuori del campus. Poiche' 128.6.4.1 e'  anche

il  gateway tra le reti 128.6.4 e 128.6.3, questo e'  il  primo

passo  per raggiungere JvNC.

   Per la comprensione dell'esempio sopra descritto si veda  lo

schizzo qui sotto.

                                       |-----|      |-----|

                                       |-----|      |-----|

                                          !!           !!

                                          !!           !! 128.6.4

                                      |----+-----------+------+----|

                                                              !! .1

                             linea seriale alta velocita'     !!

 ^^^^^^^         ------------                                 !!

/  NFS  \<======|    JvNC    |--------/\                      !!

\  net  /        ------------           \---------+           !!

 -------                                      |---|---|   |---+---|

                                              |   G   |   |   G   |

                                              |-------|   |-------|

                                                  !!          !!

                                             .12  !!          !!

                                             |-----+-----------+---|

                                                    128.6.3

   Quando  un  calcolatore vuole inviare un  datagramma,  prima

controlla  se  l'indirizzo IP di destinazione e' sulla  propria

rete  locale.  Se  cosi,  il  datagramma  puo'  essere  inviato

direttamente.  Altrimenti, il sistema  aspetta  di  trovare  un

accesso   per   la  rete  a  cui  appartiene  l'indirizzo.   Il

datagramma,  dunque,  viene  inviato  al  router  indicato  per

quell'accesso.  Queste informazioni si trovano in  una  tabella

(tabella delle rotte) che puo' essere abbastanza grande.

   Per  esempio oggi l'Internet include parecchie centinaia  di

singole  reti  e percio' si stanno sviluppando varie  strategie

per ridurre la grandezza delle tabelle di routing.

   Una   strategia   e'  quella  di  dipendere   dalla   "rotta

predefinita o default".

   Spesso  c'e'  solo  un  gateway  che  puo'  connettere   una

Ethernet locale ad una rete dorsale geografica (WAN).  In  quel

caso,  non c'e' bisogno di avere un accesso separato  per  ogni

rete  nel  mondo. Si definisce semplicemente quel gateway  come

"default". Quando per un datagramma non viene trovata una rotta

specifica,   questo  viene  inviato  al  gateway  di   default.

Quest'ultimo  puo'  anche essere usato  quando  ci  sono  molti

gateway su una rete.

   Ci  sono  degli accorgimenti  per cui i gateways inviano  un

messaggio  dicendo "non sono il migliore gateway -  usa  questo

invece"  (Il  messaggio viene inviato via ICMP;   si  veda  RFC

792).  Molto software di rete viene progettato per usare questi

messaggi  ICMP  allo scopo di aggiungere voci di  accesso  alla

loro tabella di instradamento.

   Si  immagini  per  esempio che la  rete  128.6.4  abbia  due

gateways, 128.6.4.59 e 128.6.4.1 . Il primo conduce a parecchie

altre   reti   interne   di   Rutgers.   Il   secondo   conduce

indirettamente  alla  rete  NSF.  Si  supponga  di   installare

128.6.4.59 come gateway di default, e che non si abbiano  altre

voci nella tabella delle rotte. Ora cosa accade quando si invia

un datagramma verso MIT, che e' la rete 18? Poiche' non ci sono

voci per la rete 18, il datagramma sara' inviato al gateway  di

default  128.6.4.59. Come previsto, questo  gateway  e'  quello

sbagliato.  Cosi  verra'   inoltrato  il  datagramma  verso  il

secondo,  cioe' 128.6.4.1 . Ma ritornera' un errore dicendo  in

effetti:  "per  raggiungere la rete 18 usa  il  router  con  il

numero   IP   128.6.4.1".   Il  software   aggiungera'   quella

informazione  alla  tabella delle rotte e qualsiasi  datagramma

successivo  diretto  verso MIT andra'  allora  direttamente  al

router  128.6.4.1 (il messaggio di errore viene inviato  usando

il  protocollo ICMP. Il tipo di messaggio viene chiamato  "ICMP

redirect ").

   Per la comprensione dell'esempio sopra descritto si veda  lo

schizzo qui sotto.

    ^^^^^^^                                                   --^^--

  /         \         / \                                   /        \

 /    NFS    \<----  /   \     |-------|    |-------|      /          \

 \    net    /            \----|   G   |    |   G   |=====>  Rutgers  |       

  \        /                   |-------|    |-------|      \          /

   --------                        !!            !!           -------  

                                .1 !!            !! .59

                              |----+-------------+-----|

                                        128.6.4

   Molti   esperti   di  IP  raccomandano  che  i   calcolatori

individualmente  non  dovrebbero  tentare  di  tenere   traccia

dell'intera  rete.  Invece,  essi dovrebbero  iniziare  con  un

gateway di default e lasciare che questo indichi loro le rotte,

proprio come descritto sopra.

   Comunque questo non dice come i gateways scoprono le rotte. I

   gateways  non possono dipendere da questa  strategia,  ma

devono  avere una tabella di instradamento abbastanza completa.

A tale scopo, e' necessario qualche sorta di protocollo.

   In   particolare   un  protocollo  per  l'instradamento   e'

semplicemente una tecnica utilizzata dai gateways per scoprirsi

l'un  l'altro  e  prendere  nota  della  maniera  migliore  per

raggiungere la via per ogni rete.

   L'RFC  1009  contiene una rivista di progetto di gateways  e

relative  rotte; e il documento "rip.doc" (non disponibile  per

ora)  e'  probabilmente la migliore introduzione all'argomento.

Esso  contiene  del  materiale istruttivo ed  una  discussione;

inoltre  contiene  descrizioni dettagliate  sui  protocolli  di

instradamento piu' comunemente usati.

   7.   Dettagli   sugli   indirizzi  Internet:   sottoreti   e

broadcasting

   Come  indicato prima, gli indirizzi Internet sono  numeri  a

32  bit,  normalmente scritti come quattro ottetti in notazione

decimale, nella forma "128 . 6 . 4 . 7".

   Ci  sono effettivamente tre tipi differenti di indirizzi. Il

problema  e'  che l'indirizzo deve indicare sia   la  rete  che

l'host, all'interno dell'internet.

   Si  senti' che ci sarebbero state molte reti e molte di loro

sarebbero  state  di piccole dimensioni. Probabilmente  24  bit

sarebbero stati necessari per rappresentare tutta la  rete  IP.

Si senti' inoltre, che alcune reti molto grandi avrebbero avuto

bisogno  di  24 bit per rappresentare tutti i loro hosts.  Cio'

avrebbe  condotto ad un indirizzo di 48 bit. Ma  i  progettisti

vollero  usare  decisamente  un indirizzo  a  32  bit  e  cosi'

escogitarono un trucco.

   Si  assunse  che  molte delle reti sono piccole  percio'  si

predisposero tre differenti spazi di indirizzo.

   Gli  indirizzi che iniziano con 1 fino a 126  usano  solo  i

primi  otto  bit  per il numero di rete o netid.  Gli  altri  3

ottetti sono disponibili per i numeri di hosts e cosi'  24  bit

si  rendono disponibili. Tali numeri IP vengono usati per  reti

piu' grandi. Ma ci possono essere solo 126 di queste reti molto

grandi.   Arpanet  e'  una,  e  ci  sono  anche   alcune   reti

commerciali. Ma poche organizzazioni  normali ottengono  questi

indirizzi di "classe A".

   Per  organizzazioni normalmente grandi sono usati  indirizzi

di  "classe B". Essi usano i primi due ottetti per il numero di

rete che vanno da 128.1 fino 191.254 (si evita lo zero e il 255

per  ragioni  che  si vedranno  fra poco. Si  eviteranno  anche

indirizzi  che  iniziano per 127, perche' e'  usato  da  alcuni

sistemi  per scopi speciali). Gli ultimi due ottetti, cioe'  16

bit,  rimangono  disponibili per gli indirizzi  di  host.  Cio'

permette  di  numerare fino a 64516 calcolatori che  dovrebbero

essere   abbastanza  per  molte  organizzazioni  (e'  possibile

ottenere piu' indirizzi in classe B, se si eccede tale limite).

   Finalmente  gli indirizzi di "classe C" usano  tre  ottetti,

nel  campo  tra 192.1.1 fino 223.254.254. Questi permettono  di

numerare  fino a 254 hosts in ogni rete,  ma ci possono  essere

molte di queste reti.

   Gli  indirizzi  al  di sopra di 223 sono  riservati  ad  usi

futuri come le "classi D ed E".

   Molte grandi organizzazioni trovano conveniente dividere  la

loro  rete in "sottoreti o subnets". Per esempio, a Rutgers  e'

stato  assegnato un indirizzo di classe B, 128.6. Noi  troviamo

conveniente usare il terzo ottetto dell'indirizzo per  indicare

quale  host  e'  sull'Ethernet  locale.  La  divisione  non  ha

significato  fuori da Rutgers. Un calcolatore  presso  un'altra

istituzione  tratterebbe  tutti  i  datagrammi  indirizzati  al

numero   di  rete  128.6  nella  stessa  maniera.  Questi   non

osserverebbero  il  terzo  ottetto  dell"indirizzo.   Cosi'   i

calcolatori  al  di  fuori  di  Rutgers  non  avrebbero   rotte

differenti  per  i  numeri 128.6.4 o 128.6.5,  ma  dentro,  noi

tratteremo questi ultimi come due reti separati. In  effetti  i

gateways  dentro  Rutgers  hanno  accessi  separati  per   ogni

sottorete,  invece  i gateways al di fuori  di   Rutgers  hanno

appena un accesso per la rete 128.6. Da notare che si puo' fare

esattamente la stessa cosa con un indirizzo separato di "classe

C" per ogni ethernet locale.

   Per  quanto riguarda Rutgers, sarebbe conveniente  avere  un

certo  numero  di  indirizzi classe C. Ma  usando  quest'ultimi

sarebbe  sconveniente per il resto del mondo. Ogni  istituzione

che  volesse  contattare Rutgers dovrebbe  avere  una  voce  di

accesso  per ognuna  delle sue reti locali. Se ogni istituzione

lo facesse, ci sarebbero troppe reti perche' ogni gateway possa

tenere  ragionevolmente traccia di queste. Suddividendo  invece

una  rete  di  classe B in sottoreti, si nasconde la  struttura

interna  da  tutti gli altri, e si risparmiera'  al  resto  del

mondo dei problemi.

   Questa    strategia    di   sottorete   richiede    speciali

accorgimenti per il software di rete.

   Tutto cio' e' descritto nell' RFC 950.

   0  e  255  hanno  significati speciali. 0 e' riservato  alle

macchine  che  non  conoscono  il  loro  indirizzo.  In   certe

circostanze  e' possibile per una macchina non  sapere  su  che

rete  si trova, o non sapere anche il numero del suo host.  Per

esempio, 0.0.0.23 sarebbe una macchina che sa di essere  l'host

numero 23, ma non  sa su quale rete.

   255   viene  usato  per  messaggi  "broadcast".  Essi   sono

messaggi  che  si  vuole che veda ogni sistema  sulla  rete.  I

broadcasts sono usati in alcune situazioni dove non si sa'  con

chi si sta parlando.

   Per  esempio si supponga di avere necessita' di  cercare  un

nome  di  host  e si riceva il suo numero di Internet.  Qualche

volta  non  si  conosce l'indirizzo del server  dei  nomi  piu'

vicino.  In  quel  caso  si  puo'  inviare  la  richiesta  come

broadcast.  Ci sono anche casi dove un numero di  sistemi  sono

interessati  all'informazione.  E poi meno dispendioso  inviare

un   singolo   messaggio  broadcast  che   inviare   datagrammi

individualmente    ad   ogni   host   che    e'     interessato

all'informazione. Per inviare un broadcast si usa un  indirizzo

costituito dall'indirizzo di rete, completo nella parte netid o

di rete e tutti "1" nella parte host.

   Per  esempio  se  si  e' sulla rete 128.6.4  ,  si  userebbe

128.6.4.255   come  indirizzo  broadcast.   Come   cio'   viene

effettivamente realizzato dipende dal mezzo. Non e'   possibile

per  esempio inviare messaggi broadcast su Arpanet,  o  su  una

linea  punto  a  punto. Tuttavia cio' e' possibile  sulle  reti

ethernet. Se si usa un indirizzo ethernet con tutti i suoi  bit

(FF:FF:FF:FF:FF:FF), ogni macchina osservera' quel datagramma.

   Sebbene  l'indirizzo ufficiale broadcast per la rete 128.6.4

e' oggi 128.6.4.255, ci sono alcuni altri indirizzi che possono

essere    trattati    come    broadcasts    attraverso    certe

implementazioni software.

   Per   convenienza  lo  standard  permette  di  usare   anche

255.255.255.255 . Questo si riferisce a tutti gli  hosts  sulla

rete  locale.  E'  spesso piu' semplice  usare  255.255.255.255

invece  di  scoprire il numero di rete della LAN e  formare  un

indirizzo broadcast come 128.6.4.255.

   Certe vecchie implementazioni possono usare 0 invece di  255

per  formare  l'indirizzo  broadcast  percio'  esse  userebbero

128.6.4.0 invece di 128.6.4.255 come indirizzo broadcast  sulla

rete 128.6.4.

   Ci   possono  essere  vecchie  realizzazioni  software   che

potrebbero  non comprendere le sottoreti. In questo  modo  esse

considererebbero  il  numero  di rete  128.6  dell'esempio  qui

sopra,  anzicche' 128.6.4. In quel caso, queste supporranno  un

indirizzo broadcast 128.6.255.255 oppure 128.6.0.0.

   Se  il  supporto per i messaggi broadcast viene implementato

in  maniera scorretta, puo' essere una caratteristica piuttosto

pericolosa per la rete.

   Poiche'   0   e  255  vengono  usati  rispettivamente   come

indirizzo:  sconosciuto e broadcasts, agli  hosts  normali  non

dovrebbero essere mai assegnati indirizzi contenenti 0  e  255.

Inoltre gli indirizzi non dovrebbero mai iniziare con 0 ,  127,

o nessun'altro numero al di sopra di 223.

   Gli  indirizzi che violano queste regole sono qualche  volta

indicati  come "marziani" (ci sono delle dicerie  in  giro  che

l'universita' centrale di Mars stia usando la rete 225 !!).

   8. Frammentazione e riassemblaggio di datagrammi

   TCP/IP   e'  stato  progettato  per  l'uso  su  molti   tipi

differenti  di  reti.  Sfortunatamente i progettisti  non  sono

d'accordo  su  quanto grandi i pacchetti  possano  essere.  Per

esempio  i pacchetti delle reti Ethernet possono essere  lunghi

1500  ottetti. Invece, i pacchetti Arpanet hanno un massimo  di

circa  1000  ottetti.  Mentre alcune reti  molto  veloci  hanno

misure di pacchetti piu' grandi.

      Inizialmente   si  potrebbe  pensare  che   IP   dovrebbe

semplicemente  scegliere  la  misura  piu'  piccola  possibile.

Sfortunatamente, cio' causerebbe seri problemi  in  termini  di

prestazioni.

   Per  esempio  nel  trasferimento di grossi files,  pacchetti

grandi sono molto piu' efficienti che piccoli. Dunque si  vuole

essere  in  grado  di  usare pacchetti di  misura  piu'  grande

possibile.  Si vuole anche essere in grado di gestire  le  reti

fisiche limitate in questo senso. Ci sono due possibilita'  per

raggiungere lo scopo.

   Primo,  TCP  ha la capacita' di "negoziare" sulla  grandezza

del  datagramma: quando una connessione TCP inizia, entrambi  i

capi  della comunicazione possono inviare la massima  grandezza

per  datagramma che sia loro possibile gestire. Il piu' piccolo

di   questi   numeri  viene  poi  usato  per  il  resto   della

connessione.  Questo meccanismo permette a due  implementazioni

TCP diverse di gestire grossi datagrammi, ma contemporaneamente

permette loro di conversare con implementazioni limitate.

   Tuttavia  cio'  non risolve interamente il problema.  Quello

piu'  serio  e'  che  un capo della comunicazione  non  conosce

proprio tutto sulle azioni intraprese dall'altro e viceversa.

   Per  esempio,  quando  i calcolatori sulle  reti  locali  di

Rutgers  e Berkeley si inviano dati, e' probabile che siano  su

rete  Ethernet. In questo modo essi saranno preparati a gestire

datagrammi  da  1500  ottetti.  Ma  ad  a  un  certo  punto  la

connessione  potrebbe  cadere  per  poi  riprendere  attraverso

Arpanet. Questa non puo' gestire pacchetti di quella grandezza.

Per  questa  ragione  esistono dei meccanismi  per  spezzare  i

datagrammi in pezzi: ci si riferisce alla "frammentazione".

   La  testata IP contiene campi indicanti che il datagramma e'

stato  diviso,  e  sufficienti informazioni che  permettono  ai

pezzi di essere rimessi insieme.

   Se   un  gateway  connette  una  rete  locale  Ethernet  via

Arpanet,  deve  essere preparato a ricevere pacchetti  da  1500

ottetti provenienti dalla LAN Ethernet e dividerli in pezzi che

saranno  adatti poi per il tragitto su Arpanet.  Inoltre   ogni

implementazione  di  host  TCP/IP  deve  essere  preparata   ad

accettare  pezzi  e  rimetterli insieme.  Ci  si  riferisce  al

"riassemblaggio".

   Le  realizzazioni  TCP/IP  differiscono  nell'approccio  che

esse  hanno  per  decidere sulla grandezza del  datagramma.  E'

piuttosto   comune,   per   le  varie  implementazioni,   usare

datagrammi  da 576 byte tutte le volte che queste  non  possono

verificare  che l'intero tragitto, attraverso la rete,  sia  in

grado  di  gestire  pacchetti piu'  grandi.  Questa  strategia,

piuttosto conservativa, viene usata perche' un certo numero  di

implementazioni ha dei malfunzionamenti (bachi) nel  codice  di

riassemblaggio dei frammenti.

   Gli  implementatori spesso tentano di evitare che accada  la

frammentazione.  Differenti implementatori prendono  differenti

approcci nel decidere quando e' sicuro usare grossi datagrammi.

Alcuni  li  usano  solo per reti locali altri li  useranno  per

qualsiasi rete sulla stessa zona.

   576   bytes  e'  una  grandezza  "sicura",  la  quale   ogni

implementazione deve supportare.

   9. Incapsulazione Ethernet: ARP

   C'e'  stata una breve discussione prima, su come appaiono  i

datagrammi  IP su rete fisica Ethernet. Infatti la  discussione

ha mostrato la testata Ethernet ed il checksum.

   Tuttavia   non  e'  abbastanza:  come  scoprire  l'indirizzo

Ethernet di un dato corrispondente Internet sulla propria  rete

locale?  Per risolvere cio' esiste un protocollo separato,  che

si chiama ARP ("Address Resolution Protocol").

   Da  notare a proposito che ARP non si appoggia su IP,  cioe'

i datagrammi ARP non hanno testata IP.

   Si  supponga  di  essere sul calcolatore  128.6.4.194  e  di

voler  connettere  il sistema 128.6.4.7. Il  calcolatore  prima

verifichera' che 128.6.4.7 sia sulla stessa rete fisica,  cosi'

da   interloquire  direttamente  via  Ethernet.  Poi  cerchera'

128.6.4.7  nella propria tabella ARP, per vedere se ne  conosce

gia'  l'indirizzo fisico. Se cosi, si introdurra' nella testata

Ethernet,  e  inviera'  il pacchetto. Ma  si  supponga  che  il

corrispondente  non sia nella tabella ARP:  non  c'e'  modo  di

inviare il pacchetto, perche' e' necessario l'indirizzo  fisico

del  mezzo  trasmissivo (Ethernet). Per cio' il primo  computer

usa il protocollo ARP per inviare una richiesta. Essenzialmente

una richiesta ARP dice: "ho bisogno dell'indirizzo ethernet del

sistema  128.6.4.7". Ogni calcolatore sulla rete locale ascolta

la richiesta ARP.

     Quando  un  sistema vede una richiesta ARP  indirizzata  a

se', e' previsto che risponda.

   Cosi'   il   sistema  128.6.4.7.  vedra'  la  richiesta,   e

rispondera' con una risposta ARP dicendo in effetti: "128.6.4.7

e'  il  nodo  ethernet  8:0:20:1:56:34"  (si  ricordi  che  gli

indirizzi  Ethernet sono composti di 48 bit, cioe'  6  ottetti.

Essi    vengono   convenzionalmente   mostrati   in   notazione

esadecimale,  utilizzando  la  punteggiatura  dell'esempio  qui

sopra). Quindi il sistema registrera' questa informazione nella

sua tabella ARP, e i pacchetti successivi andranno direttamente

al  corrispondente, senza l'impiego di ARP e  di  comunicazioni

broadcast.

   Molti  sistemi  tengono la tabella ARP  riposta  in  memoria

(cache), e ne ripuliscono le voci all'interno se non sono state

usate per un certo periodo di tempo.

   Da  notare  in proposito che le richieste ARP devono  essere

inviate come "broadcasts". Non c'e' modo che una richiesta  ARP

possa  essere  inviata  direttamente al  sistema  giusto.  Dopo

tutto,  la ragione per l'invio di una richiesta ARP e' che  non

si conosce l'indirizzo fisico Ethernet.

   Cosi'   viene  usato  un  indirizzo  di  tutti  "1",   cioe'

"FF:FF:FF:FF:FF:FF". Per convenzione, ad ogni   macchina  sulla

rete  Ethernet e' richiesto di prestare attenzione ai pacchetti

con  tale  indirizzo. Percio' ogni sistema vede ogni  richiesta

ARP.  Quindi  tutti  i  sistemi cercheranno  di  capire  se  la

richiesta  riguarda  il  proprio  indirizzo.  Se  cosi',   essi

risponderanno.  Se  no,  essi possono ignorarlo  (alcuni  hosts

useranno  le  richieste ARP per registrare la  loro  conoscenza

sulla rete, anche se la richiesta non e' indirizzata a loro).

   Da  notare  che  i pacchetti IP che indicano broadcast,  per

esempio: 255.255.255.255 o 128.6.4.255, vengono inviati con  un

indirizzo Ethernet formato da tutti "1".

   10. Per ottenere maggiori informazioni

   Questo  spazio  contiene una descrizione dei  documenti  che

descrivono   i   maggiori  protocolli.  Ci  sono  letteralmente

centinaia  di  documenti, cosi' sono stati  scelti  quelli  che

sembrano piu' importanti.

   Gli  standards  si  chiamano RFC che sta'  per  Request  For

Comment.  Uno standard  RFC viene inizialmente pubblicato  come

proposta,  e gli viene dato un numero. Quando viene  finalmente

accettato,   esso   viene  aggiunto  ai  Protocolli   Ufficiali

Internet, ma ci si riferisce ancora con il numero RFC.

   Sono  stati  inclusi anche due documenti IEN.  Essi  vengono

usati  per fare una classificazione separata su documenti  piu'

informali. Questa classificazione, pero', non esiste piu' da un

po':  RFC  viene  usato adesso per tutti i  documenti  Internet

ufficiali, e al posto di IEN viene impiegata una lista  postale

per inviare le relazioni piu' informali.

   La  convenzione  e'  che quando una RFC  viene  rivista,  la

versione  ottenuta  prende  un  numero  nuovo.  Questo  e'   un

approccio positivo per molti scopi, ma causa anche dei problemi

con  due  documenti:  Numeri Assegnati, e  Protocolli  Internet

Ufficiali. Essi vengono rivisti di continuo, cosi' il numero di

RFC rispecchiera' i cambiamenti.

   Si  dovrebbe guardare l'indice nel file "rfc-index.txt"  per

trovare il numero dell'ultima edizione.

   Chiunque  sia  seriamente  interessato  al  TCP/IP  dovrebbe

leggere  l'RFC 791 che descrive IP. L'RFC 1009 e'  pure  utile.

Essa e' la specifica per i gateway da impiegare su NFSnet. Come

tale,  essa contiene una rivista di gran parte della tecnologia

TCP/IP.  Si dovrebbe probabilmente leggere anche la descrizione

di  almeno  uno  dei protocolli applicativi, giusto  per  avere

un'idea  di  come le cose funzionino. La posta e' probabilmente

un  buona   esempio  (RFC 821, 822). Quella sul  TCP,  793,  e'

naturalmente una specifica basilare.

   Tuttavia le specifiche sono piuttosto complesse, percio'  si

dovrebbe leggerle solo quando si ha il tempo e la pazienza  per

farlo  attentamente.  Fortunatamente,  l'autore  della  maggior

parte  delle  RFC,  Jon Postel, e' uno scrittore  molto  buono.

Comunque l'RFC su TCP e' molto piu' facile da leggere di quanto

ci  si  aspetti,  data la complessita' della materia  che  essa

descrive.

   Si  puo' comunque dare una occhiata alle altre RFC man  mano

che si diventa curiosi sull'argomento che esse trattano.

   Ecco    una    lista   dei   documenti   che   probabilmente

interesseranno:

   Il file "rfc-index.txt" elenca tutte le RFC.

  rfc1012   Lista piuttosto piena di tutte le RFC

  rfc1011   Protocolli  Ufficiali.  E'  utile  scorrere  questo

          documento  per  vedere   lo scopo per  cui  e'  stato

          creato  un  determinato protocollo. Questa  definisce

          inoltre   quali   RFC   sono   effettivamente   degli

          Standards,   differentemente   dalle   richieste   di

          commento.

  rfc1010   Numeri  Assegnati. Se si sta lavorando con  TCP/IP,

          probabilmente si desiderera' una copia  su  carta  di

          questo  documento.  Esso non e' molto  avvincente  da

          leggere  poiche'  elenca  tutte  le  porte  (sockets)

          riservate definite e molte altre cose.

  rfc1009   Specifiche  per gateway NFSnet. Una  buona  rivista

          sulla tecnologia  di instradamento IP e i gateways.

  rfc1001/2  netBIOS: reti per PC.

  rfc973  Aggiornamento su Domain

  rfc959  FTP (trasferimento di file)

  rfc950  Sottoreti

  rfc937  POP2: protocollo per la lettura della posta  su PC.

  rfc894  Come IP viene immesso su Ethernet,si veda anche rfc825

  rfc882/3   Domains ( il database usato per tradurre da nome di

          host a indirizzo Internet e ritorno; viene usato anche

                  per gestire UUCP oggi). Si veda anche rfc973.

  rfc854/5  Telnet - protocollo per accessi remoti.

  rfc826  ARP  -  protocollo  per  scoprire  l'indirizzo Ethernet

  rfc821/2    Mail

  rfc814  Nomi  e  porte - concetti generali dietro le porte

          riservate (sockets).

  rfc793  TCP

  rfc792  ICMP

  rfc791  IP

  rfc768  UDP

  rip.doc  Dettagli sulla maggior parte dei protocolli di instradamento

  ien-116  Vecchi server dei nomi (ancora  necessari a parecchi

           tipi di sistemi)

  ien-48   Il  modello Catenet, descrizione generale della

          filosofia del TCP/IP

   I seguenti documenti sono piu' specializzati.

   rfc813  Strategie della finestra e della conferma in TCP

   rfc815  Tecnica di riassemblaggio dei datagrammi

   rfc816  Isolamento delle avarie e tecnica di risoluzione

   rfc817  Modularita' ed efficienza nelle implementazioni software

   rfc879  L'opzione della massima grandezza del segmento in TCP

   rfc896  Controllo della congestione

   rfc827, 888, 904, 975, 985   EGP e pubblicazioni relative

   Per   quelli  che possono consultare in modo  remoto  questo

documento anzicche' qui' a Rutgers:

   I  documenti RFC piu' importanti sono stati raccolti  in  un

gruppo  di  tre  volumi  - DDN Protocol  Handbook  -.  Esso  e'

disponibile  presso  il NIC del DDN ,  SRI  International,  333

Ravenswood Avenue, Menlo Park, California 94025 (telefono: 800

235-3155).  Si dovrebbe comunque essere in grado di  prelevarli

via anonymous FTP dal sito sri-nic.arpa. I File sono:

     RFC's:

       rfc:rfc-index.txt

       rfc:rfcxxx.txt

     IEN's:

       ien:ien-index.txt

       ien:ien-xxx.txt

   rip.doc   e'  disponibile  via  anonymous   FTP   dal   sito

topaz.rutgers.edu,  come  /pub/tcp-ip-docs/rip.doc.

   I  siti  con accesso alla rete UUCP, e quindi che non  hanno

la  possibilita'  di fare FTP, dovrebbero essere  in  grado  di

prelevarli via UUCP dall'host UUCP di Rutgers. I nomi di  files

sono:

     RFC's:

       /topaz/pub/pub/tcp-ip-docs/rfc-index.txt

       /topaz/pub/pub/tcp-ip-docs/rfcxxx.txt

     IEN's:

       /topaz/pub/pub/tcp-ip-docs/ien-index.txt

       /topaz/pub/pub/tcp-ip-docs/ien-xxx.txt /topaz/pub/pub/tcp-

       ip-docs/rip.doc

   Da  notare che l'ente SRI-NIC ha tutte le RFC e IEN,  mentre

rutgers e topaz hanno solo quelli menzionati di sopra.

                  _______________________________