Uni.TemiEsameSED12 History
Hide minor edits - Show changes to markup
Il protocollo è HTTP e restituisce la pagina di default del server.
Il protocollo è HTTP e / restituisce la pagina principale, senza nient'altro, senza header nè niente e la connessione viene chiusa subito dopo.
Per distinguere se è server o client devo vedere se ci sono parametri sulla linea di comando.
//Per distinguere se è server o client devo vedere se ci sono parametri sulla linea di comando.
if(argc == 1) // \\server
if(argc == 1) //server
if(sockid== -1)
if(sockid == -1)
addr.sin_family = PF_INET; addr.sin_port = 66666; addr.sin_addr = localhost;
addr.sin_family = PF_INET; addr.sin_port = 66666; addr.sin_addr = localhost;
'Considerate una applicazione di file transfer che:
# trasmette dati a tasso costante (ad esempio: il mittente genera una PDU di n bit ogni k'' millisecondi).
- resta in esecuzione per parecchio tempo.
Dovete scegliere se utilizzare TCP o UDP per questa applicazione. Fornite la vostra scelta e motivate la risposta. '''
Considerate una applicazione di file transfer che:
1. trasmette dati a tasso costante (ad esempio: il mittente genera una PDU di n bit ogni k millisecondi).
2. resta in esecuzione per parecchio tempo.
Dovete scegliere se utilizzare TCP o UDP per questa applicazione. Fornite la vostra scelta e motivate la risposta.
c:/> telnet www.dti.unimi.it 80\\ ->-> (invio) GET /\\'''
c:/> telnet www.dti.unimi.it 80 (invio) GET /'''
}
}@]
else if(argc == 2) //argc è la dimensione dela stringa, il numero di parametri passati (è la dimensione dell'argv)
else if(argc == 2) {
//inizio client //argc è la dimensione dela stringa, il numero di parametri passati (è la dimensione dell'argv) //metto argv[1] perché la porta arriva da linea di comando int porta = argv[1]; sockid = socket(PF_INET, sock_stream, 0); sockaddr_in addr { addr.sin_family = PF_INET; addr.sin_port = porta; addr.sin_addr = serveraddr; } int status = connect(sockid, &addr, lenght(addr)); //faccio il controllo solito sullo status //invio HELLO con la send //6 è la lunghezza del messaggio send(sockid, "HELLO", 6, 0); close(chi);
}
Sun XDR converte i dati nello standard big-endian prima di trasmetterli. Per quale motivo si fa? Esistono soluzioni alternative?. Mostrare in cosa consiste la conversione attraverso un esempio.
'Considerate una applicazione di file transfer che:
# trasmette dati a tasso costante (ad esempio: il mittente genera una PDU di n bit ogni k'' millisecondi).
- resta in esecuzione per parecchio tempo.
Dovete scegliere se utilizzare TCP o UDP per questa applicazione. Fornite la vostra scelta e motivate la risposta. '''
Uso TCP perché:
- affidabile: non perdo pezzi per strada
- negoziabile: negozia una scrittura adatta al tasso del client
- efficienza
'''Spiegate cosa si otterrebbe (e che protocollo si sta usando) se si digita al prompt di comando:
c:/> telnet www.dti.unimi.it 80\\ ->-> (invio)
GET /\\'''
Il protocollo è HTTP e restituisce la pagina di default del server.
//argc è la dimensione dela stringa, il numero di parametri passati (è la dimensione dell'argv)
rcv(sockid, &buffer, 1000, 0);
recv(sockid, &buffer, 1000, 0); if(buffer == "HELLO") { printf("HELLO \n"); printf("%s \n,", chi.sin_port); printf("%s \n", chi.sin_addr); }
close(chi); } //fine server e for else if(argc == 2) //argc è la dimensione dela stringa, il numero di parametri passati (è la dimensione dell'argv)
//creo buffer perché la rcv legge e scrive su buffer char buffer[1000]; //1000 è la dimensione di buffer rcv(sockid, &buffer, 1000, 0);
for(;;)
for(;;) {
sockaddr indirizzoclient; //indirizzoclient è vuoto, lo riempie la accept, e conterrà //l'indirizzo del client che mi fa la richiesta int chi = accept(sockid, &indirizzoclient, lenght(indirizzoclient));
I dati possono essere big-endian e little-endian, questi due standard consistono in un differente ordinamento dei byte. Little-endian ordina prima i byte meno significativi (ex: 12.40.119.128) mentre big-endian ordina prima i byte più significativi (ex: 128.119.40.12).
Un host può utilizzare entrambi gli ordinamenti, mentre la rete utilizza solo l’ordinamento big-endian quindi è necessario fare una conversione nell’ordine dei byte della rete prima di trasmettere (Marshalling) e un'altra conversione nel momento della ricezione(Unmarshalling). Questo processo si può schematizzare in questo modo: marshalling --> trasmissione --> ricezione --> unmarshalling

NOTA: se una macchina è già big-endian queste conversioni non fanno nulla.
Vedi slide DAM_U4_U1_L5
Con riferimento alla topologia in figura, mostrate la completa costruzione delle tabelle di instradamento RIP. Dopo quanti round si conclude l'algoritmo?
Nota:nell'immagine del prof quelle 3 righe sono più scure, ma non ho capito se è un caso o se ha un certo significato. Presumibilmente sono backbone, specie di "corsie preferenziali", ma qui è inutile saperlo perchè tanto sono tutti collegati tra loro sti nodi.

Le tabelle finali sono:
destinazione -> passo successivo -> costo
Tabella finale di RA:
RB -> RB -> 1
RC -> RC -> 1
RD -> RB -> 2
RE -> RB -> 2
RF -> RB -> 3
Tabella finale di RB:
RA -> RA -> 1
RC -> RA -> 2
RD -> RD -> 1
RE -> RE -> 1
RF -> RE -> 2
Tabella finale di RC:
RA -> RA -> 1
RB -> RA -> 2
RD -> RD -> 1
RE -> RD -> 2
RF -> RD -> 2
Tabella finale di RD:
RA -> RC -> 2
RB -> RB -> 1
RC -> RC -> 1
RE -> RE -> 1
RF -> RF -> 1
Tabella finale di RE:
RA -> RB -> 2
RB -> RB -> 1
RC -> RD -> 2
RD -> RD -> 1
RF -> RF -> 1
Tabella finale di RF:
RA -> RD -> 3
RB -> RE -> 2
RC -> RD -> 2
RD -> RD -> 1
RE -> RE -> 1
- al passo zero della tabella di ciascuno conosco solo il mio router da cui parto
- al passo 1 RA riceve i messaggi dai suoi vicini RB e RC e costruisce la sua tabella sulle loro. E così fanno tutti i nodi, ricevono tabelle dai vicini
- al passo 2 RA riceverà la tabella aggiornata di RB e RC con i cammini di RD e RE aggiornati. Altrettanto sarà per gli altri. Riceveranno quindi i messaggi dei loro vicini di due nodi più in là.
- al passo 3 RA riceverà la tabella di RB e RC aggiornata ad RF, l'ultimo rimasto. E così gli altri nodi.
L'algoritmo si conclude in 3 passi e sono tutti felici e contenti. A questo punto scrivo le tabelle richieste dall'esercizio per ciascun nodo.
Domande:
- Un utente vi racconta di aver eseguito due upload dello stesso file su altrettanti server FTP remoti e che la dimensione del file dopo averlo caricato gli appariva diversa nei due casi. Il racconto per voi è credibile? per quale motivo?
- Spiegate il significato del tipo MX di record DNS
- Fate un esempio di query diretta al DNS usando il comando nslookup
SOLUZIONE
1.
E’ possibile che accada, ad esempio perché un file una volta viene uploadato correttamente, mentre l’altro è corrotto e quindi avranno dimensioni diverse.
Oppure se si è scelto una volta il trasferimento ASCII e l’altra il trasferimento binario.
2.
Il tipo Mx significa centrale postale e consiste nella preferenza a 16 bit e nel nome dell'host che funge da centrale postale per il dominio.
E’ assegnato ai nomi usati per le centrali postali elettroniche e consente ad un sito di specificare più host in grado di accettare la posta.
Quando si invia la posta elettronica, l’utente specifica un indirizzo di posta elettronica nella forma user@domain-part. Il sistema postale utilizza il sistema dei nomi di dominio per tradurre domain-part con il tipo di interrogazione MX (preso dal libro).
3.
Nslookup consente di effettuare delle query (richieste) ad un server DNS per la risoluzione di indirizzi IP o Hostname, per poter ottenere da un dominio il relativo indirizzo IP o nome host e viceversa. Si può utilizzare in due modi: interattivo e non interattivo.
Il primo permette di effettuare più query e visualizza i singoli risultati.
Ex:
C:\>nslookup
>www.google.it
Nome: www.1.google.com
Addresses: 66.249.85.104, 66.249.85.99
Aliases: www.google.it, www.google.com
Il secondo permette di effettuare una sola query e ovviamente visualizza il risultato della singola query.
Ex:
C:\>nslookup
Server: localhost
Address: 192.168.0.19
>www.google.it
Risposta da un server non di fiducia:
Nome: www.1.google.com
Addresses: 66.249.85.104, 66.249.85.99
Aliases: www.google.it, www.google.com
(da Wikipedia)
CLIENT SMTP
#include# ...
1)Server=argv[1], utente = argv[2]
2)creazione socket sock
3)srvdata.ip=gethostbyname(server)
//nome del server che c'è sulla linea di comando
srvdata.port=25
//valore interno da convertire in big-endian
4)connect(sock, srvdata)
5)rcv(sock, msg)
//controllo che il codice msg del server sia 220 altrimenti esco
6)send(sock, "Helo 250 mioclient.it")
7)rcv(sock, msg)
//controllo che msg del server sia 250 altrimenti esco
8)send(sock, "MAIL FROM" + utente + "@mioclient.it")
9)rcv(sock, msg)
//controllo che msg del server sia 354 altrimenti esco e cacca forte
10)apro il file che contiene il messaggio di posta, descrittore fp
11)for(n=1; n>0; n= msg read(fp, buffer, EOM))
//leggo il prossimo messaggio
12){send(sock,buffer)
13)send(sock,".")}
14)close(sock)
Per distinguere se è server o client devo vedere se ci sono parametri sulla linea di comando.
[@ if(argc == 1) // \\server sockid = socket(PF_INET, SOCK_STREAM, 0); //faccio il controllo
if(sockid== -1) exit(con vergogna);
//creo la struttura sockaddr_in sockaddr_in addr { addr.sin_family = PF_INET; addr.sin_port = 66666; addr.sin_addr = localhost; } //faccio la bind int status = bind(sockid, &addr, lenght(addr)); //faccio un controllo sulla bind
if(status==-1) exit(con stile);
//faccio la listen, 10 è il numero di elementi in coda listen(sockid, 10); //inizio il ciclo infinito, andrebbe bene anche un while(1) for(;;)
(:title Temi d'esame di Sistemi - Data non pervenuta:) Torna alla pagina di Sistemi Anticoncezionali delle Reti e dei Damiani
:: Temi d'esame di Sistemi - Data non pervenuta ::
Esercizio 1
Scrivete lo pseudocodice includendo chiamate alla socket library necessarie per un programma che ripetta i seguenti requisiti:
- E' possibile attivare il programma in modalità server o client.
- In modalità server il programma non ha parametri sulla linea di comando e si mette in ascolto su una porta non usata superiore a 1024.
- In modalità client il programma riceve il numero di porta di un server sulla linea di comando e invia al server un messaggio (ad esempio "HELLO"), poi termina.
- Il server visualizza il messaggio, l'indirizzo e la porta da cui proviene. Resta in attesa di messaggi da altri client.
SOLUZIONE
CLIENT SMTP
#include# ...
1)Server=argv[1], utente = argv[2]
2)creazione socket sock
3)srvdata.ip=gethostbyname(server)
//nome del server che c'è sulla linea di comando
srvdata.port=25
//valore interno da convertire in big-endian
4)connect(sock, srvdata)
5)rcv(sock, msg)
//controllo che il codice msg del server sia 220 altrimenti esco
6)send(sock, "Helo 250 mioclient.it")
7)rcv(sock, msg)
//controllo che msg del server sia 250 altrimenti esco
8)send(sock, "MAIL FROM" + utente + "@mioclient.it")
9)rcv(sock, msg)
//controllo che msg del server sia 354 altrimenti esco e cacca forte
10)apro il file che contiene il messaggio di posta, descrittore fp
11)for(n=1; n>0; n= msg read(fp, buffer, EOM))
//leggo il prossimo messaggio
12){send(sock,buffer)
13)send(sock,".")}
14)close(sock)
Esercizio 2
Sun XDR converte i dati nello standard big-endian prima di trasmetterli. Per quale motivo si fa? Esistono soluzioni alternative?. Mostrare in cosa consiste la conversione attraverso un esempio.
SOLUZIONE
I dati possono essere big-endian e little-endian, questi due standard consistono in un differente ordinamento dei byte. Little-endian ordina prima i byte meno significativi (ex: 12.40.119.128) mentre big-endian ordina prima i byte più significativi (ex: 128.119.40.12).
Un host può utilizzare entrambi gli ordinamenti, mentre la rete utilizza solo l’ordinamento big-endian quindi è necessario fare una conversione nell’ordine dei byte della rete prima di trasmettere (Marshalling) e un'altra conversione nel momento della ricezione(Unmarshalling). Questo processo si può schematizzare in questo modo: marshalling --> trasmissione --> ricezione --> unmarshalling

NOTA: se una macchina è già big-endian queste conversioni non fanno nulla.
Vedi slide DAM_U4_U1_L5
Esercizio 3
Con riferimento alla topologia in figura, mostrate la completa costruzione delle tabelle di instradamento RIP. Dopo quanti round si conclude l'algoritmo?
Nota:nell'immagine del prof quelle 3 righe sono più scure, ma non ho capito se è un caso o se ha un certo significato. Presumibilmente sono backbone, specie di "corsie preferenziali", ma qui è inutile saperlo perchè tanto sono tutti collegati tra loro sti nodi.

SOLUZIONE
Le tabelle finali sono:
destinazione -> passo successivo -> costo
Tabella finale di RA:
RB -> RB -> 1
RC -> RC -> 1
RD -> RB -> 2
RE -> RB -> 2
RF -> RB -> 3
Tabella finale di RB:
RA -> RA -> 1
RC -> RA -> 2
RD -> RD -> 1
RE -> RE -> 1
RF -> RE -> 2
Tabella finale di RC:
RA -> RA -> 1
RB -> RA -> 2
RD -> RD -> 1
RE -> RD -> 2
RF -> RD -> 2
Tabella finale di RD:
RA -> RC -> 2
RB -> RB -> 1
RC -> RC -> 1
RE -> RE -> 1
RF -> RF -> 1
Tabella finale di RE:
RA -> RB -> 2
RB -> RB -> 1
RC -> RD -> 2
RD -> RD -> 1
RF -> RF -> 1
Tabella finale di RF:
RA -> RD -> 3
RB -> RE -> 2
RC -> RD -> 2
RD -> RD -> 1
RE -> RE -> 1
- al passo zero della tabella di ciascuno conosco solo il mio router da cui parto
- al passo 1 RA riceve i messaggi dai suoi vicini RB e RC e costruisce la sua tabella sulle loro. E così fanno tutti i nodi, ricevono tabelle dai vicini
- al passo 2 RA riceverà la tabella aggiornata di RB e RC con i cammini di RD e RE aggiornati. Altrettanto sarà per gli altri. Riceveranno quindi i messaggi dei loro vicini di due nodi più in là.
- al passo 3 RA riceverà la tabella di RB e RC aggiornata ad RF, l'ultimo rimasto. E così gli altri nodi.
L'algoritmo si conclude in 3 passi e sono tutti felici e contenti. A questo punto scrivo le tabelle richieste dall'esercizio per ciascun nodo.
Domande:
- Un utente vi racconta di aver eseguito due upload dello stesso file su altrettanti server FTP remoti e che la dimensione del file dopo averlo caricato gli appariva diversa nei due casi. Il racconto per voi è credibile? per quale motivo?
- Spiegate il significato del tipo MX di record DNS
- Fate un esempio di query diretta al DNS usando il comando nslookup
SOLUZIONE
1.
E’ possibile che accada, ad esempio perché un file una volta viene uploadato correttamente, mentre l’altro è corrotto e quindi avranno dimensioni diverse.
Oppure se si è scelto una volta il trasferimento ASCII e l’altra il trasferimento binario.
2.
Il tipo Mx significa centrale postale e consiste nella preferenza a 16 bit e nel nome dell'host che funge da centrale postale per il dominio.
E’ assegnato ai nomi usati per le centrali postali elettroniche e consente ad un sito di specificare più host in grado di accettare la posta.
Quando si invia la posta elettronica, l’utente specifica un indirizzo di posta elettronica nella forma user@domain-part. Il sistema postale utilizza il sistema dei nomi di dominio per tradurre domain-part con il tipo di interrogazione MX (preso dal libro).
3.
Nslookup consente di effettuare delle query (richieste) ad un server DNS per la risoluzione di indirizzi IP o Hostname, per poter ottenere da un dominio il relativo indirizzo IP o nome host e viceversa. Si può utilizzare in due modi: interattivo e non interattivo.
Il primo permette di effettuare più query e visualizza i singoli risultati.
Ex:
C:\>nslookup
>www.google.it
Nome: www.1.google.com
Addresses: 66.249.85.104, 66.249.85.99
Aliases: www.google.it, www.google.com
Il secondo permette di effettuare una sola query e ovviamente visualizza il risultato della singola query.
Ex:
C:\>nslookup
Server: localhost
Address: 192.168.0.19
>www.google.it
Risposta da un server non di fiducia:
Nome: www.1.google.com
Addresses: 66.249.85.104, 66.249.85.99
Aliases: www.google.it, www.google.com
(da Wikipedia)
Torna alla pagina di Sistemi Anticoncezionali delle Reti e dei Damiani