Appunti presi durante le lezioni di Sistemi di elaborazione e trasmissione dell'informazione

Implementazione di un algoritmo di scheduling con priorità

Aggiungiamo quindi la regola che: ogni s secondi, spostiamo tutti i job alla priorità più alta; questo dovrebbe prevenire la starvation, ma non impedisce a un processo di continuare a barare. Per ovviare a questo, basta tenere conto del tempo TOTALE t in cui un processo ha usato la CPU (quindi non si dà un quanto resettabile se si fanno operazioni di I/O, quando l'I/O termina il tempo "nuovo" di utilizzo della CPU viene sommato a quello precedente), al termine del quale la sua priorità viene ridotta.

L'unica problematica è che i parametri finora definiti non possono essere facilmente impostati automaticamente (quante code, quanto vale t, quanto s?). Una soluzione possibile sarebbe lavarcene le mani e lasciare la responsabilità in mano all'amministratore di sistema, ma ci sono altri approcci che vedremo successivamente.

L'RFC per il protocollo ARP è il numero 826. Si può vedere che la definizione

altro (senza avere applicazioni /protocolliapplicativi di mezzo). I datagrammi di tipo ARP hanno dunque una struttura che prevede una prima riga suddivisa in due campi da 2 byte ciascuno. Nei primi 16 bit è definito il tipo di hardware e negli altri 16 il tipo di protocollo (questo vuol dire che sono stati definiti dei numeri su 16 bit sulle possibili implementazioni del data link e sul protocollo di networking: al giorno d’oggi questi campi sono “fissi” a Ethernet e IPv4, cioè 1 per ethernet e 0x800 per IPv4). Dopodiché abbiamo, alla seconda riga, due byte separati in cui sono indicate le dimensioni degli indirizzi: cioè dell’indirizzo MAC e dell’Indirizzo IP (6 e 4). Seguono 16 bit che sono il numero di operazione (richiesta = 1/risposta = 2). Ci sono poi 6 byte (su una terza riga e metà quarta) per l’indirizzo MAC del mittente e 4 byte per l’indirizzo IP del mittente su metà quarta e metà quinta; su

metà quinta e sesta 6 byte che sono l'indirizzo MAC Target e infine, su settima 4 byte che contengono L'indirizzo IP che vogliamo tradurre (con la richiesta), che stiamo cercando (e che verranno inizializzati con la risposta).

Per fare la richiesta ARP un host deve compilare nell'header Ethernet come indirizzo di destinazione l'indirizzo di broadcast (tutti 1 nel MAC) e inizializzare tutti i campi tranne l'indirizzo MAC Target nell'header ARP.

Tutte le macchine della rete ricevono il messaggio e se un sistema operativo nota il proprio indirizzo IP nell'header ARP questo invia la risposta, inserendo i propri IP e MAC come sender IP e sender MAC e come target IP e target MAC (sì, è ridondante), ma non prima di aver modificato l'header ethernet in modo da mettere come MAC di destinazione quello dell'host che aveva fatto la richiesta: in questo modo solo chi ha fatto la richiesta riceverà la risposta.

Tutte le

DHCP è basato su UDP, utilizza la porta 68 per il server e la porta 67 per il client. Il motivo di tale scelta è che UDP permette di utilizzare l'indirizzo di broadcast per i messaggi (in questo modo si può inviare la richiesta su qualsiasi rete anche se non si conosce l'indirizzo preciso del server). La richiesta arriverà su tutte le macchine sulla porta 68, ma soltanto il server DHCP non ignorerà la richiesta (visto che sarà l'unico in ascolto lì). Per l'indirizzo mittente, invece, si mette la costante 0.

A livello di trasporto abbiamo le porte 67 e 68, a livello di networking abbiamo l'indirizzo 0 e l'indirizzo broadcast, poi abbiamo il payload DHCP.

Il server DHCP avrà una tabella di indirizzi disponibili, quindi quando riceve una richiesta preparerà una risposta, inserendo nel campo DHCP del datagramma quello assegnato (il resto del datagramma sarà uguale con la differenza che...

indirizzi e porte sorgenti e destinazione sono invertiti: solo che al posto di esserci l'indirizzo di broadcast ci saranno gli indirizzi IP e MAC del server DHCP). Il messaggio arriverà a destinazione (anche se l'IP destinazione è 0) sfruttando il fatto che nel messaggio di richiesta ci sarà stato l'indirizzo MAC del nuovo host, quindi mettendo quello come destinazione sarà possibile recapitare la risposta.

MAC (Destinazione, Sorgente) IP (Destinazione, Sorgente) UDP (Dest., Sorg.) DHCP

BroadCast, Client | BroadCast, 0 | 68, 67 | -

Client, Server | 0, Server | 67, 68 | IPDisponibile.

Se sulla rete locale sono stati configurati più server DHCP, tutti quanti riceveranno la richiesta: dunque un client potrebbe ricevere più di una risposta, ognuna con indirizzi IP potenzialmente diversi. Il protocollo prevede quindi che ci sia un ulteriore scambio di informazioni. C'è quindi un terzo messaggio "di accettazione", che

viene mandato inbroadcast a tutti. Il messaggio conterrà l'indirizzo del server scelto dal client (cioè l'indirizzo del server che ha fornito l'IP scelto dal client) tra quelli che gli hanno risposto; in questo modo ciascuno dei server saprà se il nuovo host userà l'indirizzo che gli ha inviato lui oppure no. Pertanto, ognuno di essi saprà se tenere bloccato quell'indirizzo IP per la nuova macchina (e quindi toglierlo dalla tabella di quelli disponibili per etichettarlo come assegnato) oppure no.

C'è una fase finale: dopo l'accettazione, l'unico server che ha ricevuto responso positivo (notando che il suo indirizzo è quello usato dal client) invia al client le informazioni necessarie per l'utilizzo della rete. Tipicamente, oltre all'indirizzo IP questo messaggio conterrà la Netmask, la Default Gateway (la rete che connette il router con l'esterno) e il DNS locale (per poter

fare la risoluzione di indirizzi simbolici) + una “data di scadenza” dell’indirizzo IP.

Uno potrebbe predefinire gli indirizzi MAC corrispondenti agli indirizzi IP (e quindi riservare alcuni indirizzi IP a particolari indirizzi MAC) attraverso la configurazione del server DHCP.

Alcuni ISP offrono servizi a pagamento per dare a una stessa macchina sempre lo stesso indirizzo IP.

L’RFC di riferimento per il protocollo DHCP è il 2131.

Il payload DHCP alla prima riga è strutturato così: I primi 4 byte indicano l’operazione del messaggio (1 = richiesta, 2 = risposta), poi abbiamo il tipo di hardware (che indica il protocollo di livello Data Link che stiamo utilizzando), poi la lunghezza dell’indirizzo MAC (cioè 6) e un quarto numero che nel caso normale deve essere 0. Alla seconda riga abbiamo un unico numero da 4 byte che è un numero casuale che identifica la transazione. Dopodiché, abbiamo 2 byte che codificano il numero di

secondi che sono trascorsi dall'inizio della richiesta da parte del client.

Abbiamo altri 2 byte contenenti flags.

Poi abbiamo l'indirizzo IP del client su 4 byte, che all'inizio varrà 0.

Poi abbiamo altri 4 byte per l'indirizzo IP proposto dal server e altri 4 byte per l'indirizzo IP del server (così che il client lo possa ricontattare, anche se è ridondante perché si trova già a livello di networking).

Poi abbiamo l'indirizzo IP di un eventuale Proxy (che potrebbe intervenire tra client e server).

Poi abbiamo 16 byte per il client hardware address e poi ci sono altri 64 byte che corrispondono al server hostname (è una stringa di massimo 63 caratteri terminati da 0) e sono un campo opzionale.

Ci sono poi 128 byte che rappresentano il boot file_name e infine ci sono delle Opzioni che possono esserci o non esserci.

In questo caso il meccanismo di sicurezza è costituito dal Random Trans # presente nella seconda riga.