LIVELLO 4: TRASPORTO

Il livello 4 ha il compito di delivery, ovvero deve garantire la corretta trasmissione dei pacchetti, ovvero deve correggere gli errori del livello 3 (livello rete). La presenza dell’errore se è segnalata è solo una perdita di tempo per richiedere il pacchetto corretto, altrimenti il livello di trasporto deve individuare l’errore.

TP0 protocollo di livello trasporto che opera molteplicità singola sui servizi di rete di tipo A: bassa percentuale di errori segnalati e bassi errori non segnalati.

TP2 errori segnalati qualsiasi, errore residui alti, di tipo C

TP4 protocollo di livello trasporto che opera a molteplicità singola su servizi di rete di tipo C.

Il livello 4 non deve far ricadere nell’utente gli errori di livello 3.

La connettività non si misura solo al livello fisico, ma in tutto il percorso. Possono quindi commettere errori tutti i livelli protocollari.

MECCANISMI DI TRASPORTO PER SERVIZI DI RETE IDEALI

Il primo problema è quello di conoscere l’indirizzo del sistema che si vuol contattare. Per contattare un host si deve conoscere Sap che indica l’utente del livello trasporto, entità che identifica il processo di livello trasporto e Nsap che rappresenta il nodo in cui l’utente è allocato.

Per acquisire Sap abbiamo metodi dinamici o statici. Al livello statico: all’avvio del sistema si avvia una configurazione per assegnare Sap prefissati.

A livello dinamico possiamo individuare la name-server e la processor-server. Entrambe ricorrono a una entità ulteriore. La prima interpella il server del livello trasporto, e richiede l’identificativo dell’utente del livello di trasporto. Mentre il processor-server viene usato quando i processi richiesti non sono sempre attivi, ovvero i processi remoti, deve inoltre collegarsi con un dominio pubblico al server.

Richiesta di connessione: Per richiedere una connessione

  1. emetto una request
    1. se la connessione è impossibile mi arriva una disconnect
    2. se è accettata mi arriva una confirm
  2. se non è accettata mi pongo in ascolto
    1. arriva una richiesta di connessione (indication) a cui rispondo con confirm
    2. smetto di restare in ascolto.

Trasferimento dati: anche le entità devono avere un buffer. Dobbiamo però limitare la saturazione del buffer

  • Eliminiamo i pacchetti che non ci stanno
  • Assegnazione di un numero di sequenza ai singoli pacchetti.
  • Gestioni di pacchetti numerate
  • Allocazione dinamica del buffer: viene rispedito un pacchetto che indica che il buffer è pieno.

Rilascio della connessione:

  1. emetto una request per sconnettermi
  2. sconnessione accettata
  3. ricevo una richiesta di sconnessione
  4. emetto una conferma di sconnessione

MECCANISMI DI TRASPORTO IN PRESENZA DI ERRORI

I problemi principali derivano dall’arrivo non ordinato o corrotto o dalla possibile presenza di duplicazioni. In caso di arrivo non ordinato si inserisce un informazione per ordinare i pacchetti in arrivo, se sono corrotti e si accorge per le informazioni di controllo errate richiede la ritrasmissione adottando le tecniche per non saturare il buffer appena descritte.

In caso di pacchetti duplicati se si manda un riscontro otteniamo ancora maggiori problemi in caso di nuova duplicazione. Devono quindi essere numerate anche quelle di controllo.

morocarlo

Sono uno studente di ingegneria informatica all'università di trieste. Sono appassionato di tecnologia, principalmente mi occupo/interesso di reti, hardware e software in generale. Programmo molto in Visual Basic .net (2008), ma conosco molto bene VB6. Ho le conoscenze basilari dei maggiori linguaggi di programmazione come php, asp, java, js, C#, Pascal e Assembly. SO: Windows 7, XP, Ubuntu, Mint, Netbook Remix

Lascia un commento

Il tuo indirizzo email non sarà pubblicato. I campi obbligatori sono contrassegnati *