Frammentazione dei Pacchetti

E'molto facile che i datagrammi UDP siano frammentati in piu' pacchetti. Molti applicativi che usano UDP tendono ad impiegare messaggi molto lunghi (NFS usa buffer di 8 kbyte) per tentare di far entrare molte informazioni in un singolo datagramma.

Teoricamente la massima dimensione di un pacchetto IP e' 65535 byte; con in piu' le testate UDP e IP si arriva ad un massimo teorico di 65507 byte di dat in un datagramma UDP.

Il limite pratico puo' essere inferiore per due motivi:

• Non tutte le librerie di interfaccia ai socket permettono datagrammi cosi' grandi: la maggior parte permette 8192 byte o poco piu'
• Nell'implementazione dei protocolli TCP/IP nel kernel vi sono spesso limitazioni alla dimensione massima di un pacchetto, volute o per errore

Un effetto perverso si ha quando la rete supporta l'invio di datagrammi grandi ma l'applicativo ricevente ha un buffer di ricezione molto limitato. Molti applicativi che lavorano con UDP in questo caso semplicemente troncano il datagramma in ricezione, scartando i dati in eccesso.

Alcune versioni antiche di Berkley UNIX addirittura non notificano l'applicativo che il datagramma e' stato troncato.

Versioni derivate da UNIX SVR4 non scartano i dati in eccesso ma eseguono piu' letture del datagramma per incamerare tutti i dati in arrivo. A volte l'applicativo non e' conscio di aver eseguito piu' letture.

L'interfaccia TLI (Transport Level Interface) della AT&T non scarta i dati, ma ritorna un flag all'applicativo per indicare la necessita' di ulteriori operazioni di lettura.

Interazione UDP - Altri Protocolli

Naturalmente, dato il volume di dati che UDP puo' generare su rete e la possibilita' elevata di frammentazione, il caso piu' frequente e' la generazione di messaggi ICMP:

• Source Quench - per indicare la necessita' di ridurre la velocita' di invio pacchetti Per un periodo di tempo la moda e' stata di deprecare l'uso di messaggi Source Quench ritenuti solo un ulteriore aggravio del carico di rete ed inefficaci nel ridurre le congestioni. La moda attuale e' tornata a favorirli, come metodo di feedback per programmi adattativi; i programmi inoltre tendono ad iniziare lentamente ad inviare i pacchetti, per poi aumentare gradualmente fino al primo Source Quench.
• Destination Unreachable - codice indicante frammentazione necessaria ma bir Don't Fragment settato. Molte versioni UNIX, p.es. Solaris, preferiscono negoziare un Path MTU piuttosto che frammentare i pacchetti di continuo. Purtroppo il timeout di rinegoziazione del Path MTU, che dovrebbe essere di 10 minuti secondo le specifiche, e' spesso settato troppo corto, 30 secondi o meno.
• Time Exceeded - codice indicante dempo scaduto durante il riassemblaggio pacchetti. Attenzione che alcune versioni vecchie di Berkeley UNIX non generano mai questo messaggio.

Uno strano effetto di interazione tra UDP ed ARP si verifica quando i datagrammi sono appena superiori in dimensione a 8192 byte e abbisognano di frammentazione. Piu' frammenti sono generati e ciascuno di essi causa l'invio di una richiesta ARP. ARP scarta tutti i frammenti tranne l'ultimo (e' parte delle specifiche), ma genera le richieste troppo velocemente (non e' parte delle specifiche, che dicono di attendere circa un secondo tra due richieste successive alla stessa stazione). Quando un responso ARP arriva, lo ARP della stazione inviante ha gia' scartato tutti i pacchetti, tranne l'ultimo che viene inviato. Lo strato UDP del ricevente non ha la testata UDP in questo pacchetto e, non sapendo a quale porto destinarlo, lo scarta silenziosamente. Dopo un tempo di timeout, l'applicativo inviante ripete la trasmissione, che questa volta passa immediatamente poiche lo ARP inviante gia' possiede la destinazione nella sua cache.

Attenzione che in questo caso, se il tempo di validita' della cache ARP e' inferiore al tempo di ritrasmissione dell'applicativo inviante, l'effetto malefico viene ripetuto e forse il datagramma non arrivera' mai a destinazione.