Cos'è il TCP/IP - IV3IUM-2020

Cerca
Vai ai contenuti

Menu principale:

Doc TCP/IP

                        INTRODUZIONE
               AI     PROTOCOLLI     INTERNET
            Computer  Science  Facilities  Group
                          RUTGERS
             The State University of New Jersey
                        3 Luglio 1987

      Copyright (C) 1987 Charles L. Hedrick .
                         

                          Presentazione
                                
  Eccovi   un'introduzione  ai  protocolli  di  rete  Internet
TCP/IP. E'inclusa anche una panoramica sui servizi disponibili e
una breve descrizione dei maggiori protocolli della famiglia.
  Ritengo  questo scritto una lettura accattivante  e  non  un
noioso documento tecnico, che richiede una certa preparazione in
materia.
  Infatti  il  testo, sebbene un po' datato, descrive  con  un
linguaggio  semplice, ma appropriato, i concetti  fondamentali,
sempre  attuali,  che  sono alla base della  tecnologia  TCP/IP
consentendo   la   comprensione   immediata   e   lo    stimolo
all'approfondimento.
  Ed  e'  proprio cosi' che deve essere intesa questa lettura:
l'approccio disimpegnato al mondo Internet, ma anche il punto di
partenza per uno studio da compiere con l'ausilio di  testi piu'
specializzati. A tal proposito vorrei indicare un testo di
consultazione  molto valido: "Internetworking with  TCP/IP"  di
Douglas  Comer edito dalla McGraw Hill, (reperibile in italiano
per una settantina di mila lire).
  Lo scritto che segue e' rivolto sia, a chi si avvicina per la
prima volta al mondo della telematica e delle reti, e sia  a chi
e'  gia'  introdotto ed opera con il  TCP/IP.  Infatti  vi
troveranno   indicazioni   e  concetti   preziosi   anche   gli
amministratori di sistemi di rete.
  Vi  auguro  che cio' sia l'inizio di curiosita' ed interesse
per  la materia trattata, cosi' come e' accaduto allo scrivente
cinque  anni  fa.  Se  cio' accadra', vi  assicuro  che  sarete
ripagati ampiamente degli sforzi fatti per capire ed operare in
TCP/IP e  le soddisfazioni non tarderanno a venire!

                         Buona lettura   da   Lino Pizzichetti

                   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.




                   _______________________________



.

 
Torna ai contenuti | Torna al menu