cerca
Domande Damiani
modifica cronologia stampa login logout

Wiki

UniCrema


Materie per semestre

Materie per anno

Materie per laurea


Help

Return to Domande Damiani  (Edit)

Uni.DomandeDamiani History

Hide minor edits - Show changes to output

Changed line 74 from:
[[Torna alla pagina di Sistemi Anticoncezionali delle Reti e dei Damiani->Sistemi]]
to:
[[Torna alla pagina di Sistemi per l'elaborazione delle informazioni->Sistemi]]
Changed line 2 from:
[[Torna alla pagina di Sistemi Anticoncezionali delle Reti e dei Damiani->Sistemi]]
to:
[[Torna alla pagina di Sistemi per l'elaborazione delle informazioni->Sistemi]]
Changed lines 65-66 from:
Da '''Francesco''': ''"Visto che la domanda è "aperta" (non specifica dove avviene la connessione, se la rete è congestionata o meno) e può dar luogo a diverse risposte, io aggiungo la mia. E' possibile anche avere un flusso ibrido TCP/UDP, nel senso che, una prima parte del flusso lo effettuo con connessione TCP e se gli ACK arrivano tutti correttamente procedo con UDP visto che si ipotizza che la trasmissione sia funzionale.
Se invece gli ACK tardano a ritornare o ci sono molti problemi sulla linea, UDP non sarebbe più una soluzione ottimale visto che non si ha nessuna garanzia che il pacchetto arrivi a destinazione (anche a fronte di quello che ha detto Mirco sull'impercettbilità del pacchetto mancante)per cui si procede solamente con TCP.....Francesco"''
to:
Da '''Francesco''': ''"Visto che la domanda è "aperta" (non specifica dove avviene la connessione, se la rete è congestionata o meno) e può dar luogo a diverse risposte, io aggiungo la mia. E' possibile anche avere un flusso ibrido TCP/UDP, nel senso che, una prima parte del flusso lo effettuo con connessione TCP e se gli ACK arrivano tutti correttamente procedo con UDP visto che si ipotizza che la trasmissione sia funzionale. Se invece gli ACK tardano a ritornare o ci sono molti problemi sulla linea, UDP non sarebbe più una soluzione ottimale visto che non si ha nessuna garanzia che il pacchetto arrivi a destinazione (anche a fronte di quello che ha detto Mirco sull'impercettbilità del pacchetto mancante)per cui si procede solamente con TCP.....Francesco"''
Changed lines 62-64 from:
Da '''wikipedia''': ''"Dato che le applicazioni in tempo reale spesso richiedono un ritmo minimo di spedizione, non vogliono ritardare eccessivamente la trasmissione dei pacchetti e possono tollerare qualche perdita di dati, il modello di servizio TCP può non essere particolarmente adatto alle esigenze di queste applicazioni"''
Da '''Mirco''': ''"EFFETTIVAMENTE LA PERDITA DI UN PACCHETTO DI UN FLUSSO AUDIO O VIDEO NON COMPORTA L'IMPOSSIBILITà DI SENTIRE O VEDERE IL FILMATO POICHè UN PACCHETTO, A GRANDI LINEE, CONTIENE UN MILLI-MICRO SECONDO DI FLUSSO AUDIO O VIDEO, IL CHE, ALL'OCCHIO O ALL'UDITO UMANO RISULTEREBBE QUASI IMPERCETTIBILE; Mirco"''
Da '''Dario''': ''"Anche io ricordo che aveva parlato dell'utilizzo di UDP proprio nei casi in cui non sia necessario ogni singolo pacchetto, e l'esempio era proprio la trasmissione di audio/video... Dario."''
to:
Da '''wikipedia''': ''"Dato che le applicazioni in tempo reale spesso richiedono un ritmo minimo di spedizione, non vogliono ritardare eccessivamente la trasmissione dei pacchetti e possono tollerare qualche perdita di dati, il modello di servizio TCP può non essere particolarmente adatto alle esigenze di queste applicazioni"''\\
Da '''Mirco''': ''"EFFETTIVAMENTE LA PERDITA DI UN PACCHETTO DI UN FLUSSO AUDIO O VIDEO NON COMPORTA L'IMPOSSIBILITà DI SENTIRE O VEDERE IL FILMATO POICHè UN PACCHETTO, A GRANDI LINEE, CONTIENE UN MILLI-MICRO SECONDO DI FLUSSO AUDIO O VIDEO, IL CHE, ALL'OCCHIO O ALL'UDITO UMANO RISULTEREBBE QUASI IMPERCETTIBILE; Mirco"''\\
Da '''Dario''': ''"Anche io ricordo che aveva parlato dell'utilizzo di UDP proprio nei casi in cui non sia necessario ogni singolo pacchetto, e l'esempio era proprio la trasmissione di audio/video... Dario."''\\
Changed lines 62-83 from:
Siccome con UDP non è garantito che arrivi a qualunque punto della rete e ho bisogno del ritorno dell'ACK, uso TCP che è più affidabile

"CREDO CHE QUESTA RISPOSTA NON SIA CORRETTA
, PUR AMMETTENDO DI NON AVER SEGUITO MOLTE LEZIONI DEL PROFESSOR DAMIANI;
WIKIPEDIA RIPORTA QUANTO SEGUE:

''"Dato che le applicazioni in tempo reale spesso richiedono un ritmo minimo di spedizione, non vogliono ritardare eccessivamente la trasmissione dei pacchetti e possono tollerare qualche perdita di dati, il modello di servizio TCP può non essere particolarmente adatto alle esigenze di queste applicazioni"''

EFFETTIVAMENTE LA PERDITA DI UN PACCHETTO DI UN FLUSSO AUDIO O VIDEO NON COMPORTA L'IMPOSSIBILITà DI SENTIRE O VEDERE IL FILMATO POICHè UN PACCHETTO, A GRANDI LINEE
, CONTIENE UN MILLI-MICRO SECONDO DI FLUSSO AUDIO O VIDEO, IL CHE, ALL'OCCHIO O ALL'UDITO UMANO RISULTEREBBE QUASI IMPERCETTIBILE;
Mirco
"
--------------------------------------------------------------------------------------

-> Anche io ricordo che aveva parlato dell'utilizzo di UDP proprio nei casi in cui non sia necessario ogni singolo pacchetto
, e l'esempio era proprio la trasmissione di audio/video... Dario.

----------------------------------------------------------------------------------------


Visto che la domanda è "aperta" (non specifica dove avviene la connessione, se la rete è congestionata o meno) e può dar luogo a diverse risposte, io aggiungo la mia.

E' possibile anche avere un flusso ibrido TCP/UDP, nel senso
che, una prima parte del flusso lo effettuo con connessione TCP e se gli ACK arrivano tutti correttamente procedo con UDP visto che si ipotizza che la trasmissione sia funzionale.
Se invece gli ACK tardano a ritornare o ci sono molti problemi sulla linea, UDP non sarebbe più una soluzione ottimale visto che non si ha nessuna garanzia che il pacchetto arrivi a destinazione (anche a fronte di quello che ha detto Mirco sull'impercettbilità del pacchetto mancante)per cui si procede solamente con TCP.....Francesco
to:
Da '''wikipedia''': ''"Dato che le applicazioni in tempo reale spesso richiedono un ritmo minimo di spedizione, non vogliono ritardare eccessivamente la trasmissione dei pacchetti e possono tollerare qualche perdita di dati, il modello di servizio TCP può non essere particolarmente adatto alle esigenze di queste applicazioni"''
Da '''Mirco''': ''"EFFETTIVAMENTE LA PERDITA DI UN PACCHETTO DI UN FLUSSO AUDIO O VIDEO NON COMPORTA L'IMPOSSIBILITà DI SENTIRE O VEDERE IL FILMATO POICHè UN PACCHETTO, A GRANDI LINEE, CONTIENE UN MILLI-MICRO SECONDO DI FLUSSO AUDIO O VIDEO, IL CHE, ALL'OCCHIO O ALL'UDITO UMANO RISULTEREBBE QUASI IMPERCETTIBILE; Mirco"''
Da '''Dario''': ''"Anche io ricordo che aveva parlato dell'utilizzo di UDP proprio nei casi in cui non sia necessario ogni singolo pacchetto
, e l'esempio era proprio la trasmissione di audio/video... Dario."''
Da
'''Francesco''': ''"Visto che la domanda è "aperta" (non specifica dove avviene la connessione, se la rete è congestionata o meno) e può dar luogo a diverse risposte, io aggiungo la mia. E' possibile anche avere un flusso ibrido TCP/UDP, nel senso che, una prima parte del flusso lo effettuo con connessione TCP e se gli ACK arrivano tutti correttamente procedo con UDP visto che si ipotizza che la trasmissione sia funzionale.
Se invece gli ACK tardano a ritornare o ci sono molti problemi sulla linea, UDP non sarebbe più una soluzione ottimale visto che non si ha nessuna garanzia che il pacchetto arrivi a destinazione (anche a fronte di quello che ha detto Mirco sull'impercettbilità del pacchetto mancante)per cui si procede solamente con TCP.....Francesco"''
Changed lines 71-72 from:
to:
--------------------------------------------------------------------------------------
Added lines 74-83:

----------------------------------------------------------------------------------------


Visto che la domanda è "aperta" (non specifica dove avviene la connessione, se la rete è congestionata o meno) e può dar luogo a diverse risposte, io aggiungo la mia.

E' possibile anche avere un flusso ibrido TCP/UDP, nel senso che, una prima parte del flusso lo effettuo con connessione TCP e se gli ACK arrivano tutti correttamente procedo con UDP visto che si ipotizza che la trasmissione sia funzionale.
Se invece gli ACK tardano a ritornare o ci sono molti problemi sulla linea, UDP non sarebbe più una soluzione ottimale visto che non si ha nessuna garanzia che il pacchetto arrivi a destinazione (anche a fronte di quello che ha detto Mirco sull'impercettbilità del pacchetto mancante)per cui si procede solamente con TCP.....Francesco
Added line 72:
-> Anche io ricordo che aveva parlato dell'utilizzo di UDP proprio nei casi in cui non sia necessario ogni singolo pacchetto, e l'esempio era proprio la trasmissione di audio/video... Dario.
Added lines 63-71:

"CREDO CHE QUESTA RISPOSTA NON SIA CORRETTA, PUR AMMETTENDO DI NON AVER SEGUITO MOLTE LEZIONI DEL PROFESSOR DAMIANI;
WIKIPEDIA RIPORTA QUANTO SEGUE:

''"Dato che le applicazioni in tempo reale spesso richiedono un ritmo minimo di spedizione, non vogliono ritardare eccessivamente la trasmissione dei pacchetti e possono tollerare qualche perdita di dati, il modello di servizio TCP può non essere particolarmente adatto alle esigenze di queste applicazioni"''

EFFETTIVAMENTE LA PERDITA DI UN PACCHETTO DI UN FLUSSO AUDIO O VIDEO NON COMPORTA L'IMPOSSIBILITà DI SENTIRE O VEDERE IL FILMATO POICHè UN PACCHETTO, A GRANDI LINEE, CONTIENE UN MILLI-MICRO SECONDO DI FLUSSO AUDIO O VIDEO, IL CHE, ALL'OCCHIO O ALL'UDITO UMANO RISULTEREBBE QUASI IMPERCETTIBILE;
Mirco"
Changed lines 45-47 from:
Se lo manda all'indirizzo di rete crea un vero e proprio frame ethernet, lo scrive sul filo e se lo manda.
Se manda un pacchetto al loop fa una copia del pacchetto memoria su memoria, il pacchetto quindi in realtà non passa mai per la rete.
to:
Se lo manda all'indirizzo di rete crea un vero e proprio frame ethernet, lo scrive sul filo e se lo manda. Se manda un pacchetto al loop fa una copia del pacchetto memoria su memoria, il pacchetto quindi in realtà non passa mai per la rete.
Changed line 44 from:
* %green% '''Specificare la sequenza di eventi quando una macchina manda il pacchetto al proprio indirizzo di rete o al loop'''\\
to:
* %green% '''Specificare la sequenza di eventi quando una macchina manda il pacchetto al proprio indirizzo di rete o al loop'''%%\\
Changed lines 48-51 from:
* %green% '''Quali sono le condizioni di integrità sul pacchetto?'''\\
IL pacchetto che ci sta in un frame ethernet deve starci anche in un frame di una rete diversa, altrimenti le due reti non possono comunicare. Per fare in modo che ciò avvenga il frame della rete più piccola deve essere grosso almeno quanto l'header IP dell'altra, altrimenti non sarà possibile trasmettre nessun payload.

* %green% '''Differenze UDP e TCP?'''\\
to:
* %green% '''Quali sono le condizioni di integrità sul pacchetto?'''%%\\
Il pacchetto che ci sta in un frame ethernet deve starci anche in un frame di una rete diversa, altrimenti le due reti non possono comunicare. Per fare in modo che ciò avvenga il frame della rete più piccola deve essere grosso almeno quanto l'header IP dell'altra, altrimenti non sarà possibile trasmettre nessun payload.

* %green% '''Differenze UDP e TCP?'''%%\\
Changed line 59 from:
* %green% '''Differenze banda nominale banda reale'''\\
to:
* %green% '''Differenze banda nominale banda reale'''%%\\
Changed line 62 from:
* %green% '''Avete un flusso audio-video, lo mando su TCP o su UDP?'''\\
to:
* %green% '''Avete un flusso audio-video, lo mando su TCP o su UDP?'''%%\\
Changed line 44 from:
* %green% '''Specificare la sequenza di eventi quando una macchina manda il pacchetto al proprio indirizzo di rete o al loop'''
to:
* %green% '''Specificare la sequenza di eventi quando una macchina manda il pacchetto al proprio indirizzo di rete o al loop'''\\
Changed line 48 from:
* %green% '''Quali sono le condizioni di integrità sul pacchetto?'''
to:
* %green% '''Quali sono le condizioni di integrità sul pacchetto?'''\\
Changed lines 51-52 from:
* %green% '''Differenze UDP e TCP?'''
UDP fornisce un servizio inaffidabile e non orientato alla connessione. La sua unica funzione è quella del multiplexing
to:
* %green% '''Differenze UDP e TCP?'''\\
UDP fornisce un servizio inaffidabile e non orientato alla connessione. La sua unica funzione è quella del multiplexing.\\
Changed lines 54-59 from:
° controllo di flusso end to end
° controllo di congestione end to end
° ritrasmissione di PDU persi o corrotti
° consegna nella corretta sequenza delle unità dati

* %green% '''Differenze banda nominale banda reale'''
to:
** controllo di flusso end to end
** controllo di congestione end to end
** ritrasmissione di PDU persi o corrotti
** consegna nella corretta sequenza delle unità dati

* %green% '''Differenze banda nominale banda reale'''\\
Changed line 62 from:
* %green% '''Avete un flusso audio-video, lo mando su TCP o su UDP?'''
to:
* %green% '''Avete un flusso audio-video, lo mando su TCP o su UDP?'''\\
Changed lines 66-70 from:
°tipo di servizio\\
°protocollo\\
°flag\\
°IHL
to:
** tipo di servizio
** protocollo
** flag
** IHL
Changed lines 66-68 from:
°tipo di servizio
°protocollo
°flag
to:
°tipo di servizio\\
°protocollo\\
°flag\\
Added lines 65-70:
* %green% '''Possibili domande sullo Header IP'''
°tipo di servizio
°protocollo
°flag
°IHL
Added lines 62-64:
* %green% '''Avete un flusso audio-video, lo mando su TCP o su UDP?'''
Siccome con UDP non è garantito che arrivi a qualunque punto della rete e ho bisogno del ritorno dell'ACK, uso TCP che è più affidabile
Changed lines 26-28 from:
** DHCP assegna dinamicamente gli indirizzi IP;
** ARP invece serve per far costruire agli host delle tabelle in cui si associano indirizzi
IP e MAC.
to:
** DHCP assegna dinamicamente gli indirizzi IP. Se un pc si collega a una rete in cui c'è DHCP, dovrà chiedergli un indirizzo IP per viaggiare su quella rete. Il pc in questione perciò invia un messaggio con il suo MAC e gli viene data risposta con IP, sottomaschera di rete, default gateway e a volte anche l'indirizzo del DNS ''(Domain Name Server)''. Attenzione! C'è una scadenza per questo indirizzo decisa dal programmatore del DHCP, scaduto questo tempo dovrò inoltrare nuova richiesta.
** ARP invece serve per far costruire agli host delle tabelle in cui si associano indirizzi IP e MAC. E' ARP stesso che manda un messaggio broadcast per farsi dare tutti gli indirizzi. Questa tabella viene aggiornata quando si connette un nuovo pc. Siano A l'host mittente e B l'host di cui non si conosce il MAC address. L'host A invia una richiesta in broadcast indicando l'indirizzo IP di B. B risponderà ad A con una reply unicast. Ogni pc ha una cache in cui memorizza le risoluzioni più recenti
.
Changed lines 36-37 from:
Facendo il test del prefisso.
to:
Facendo il test del prefisso (la famosa roba che mette in AND il mio indirizzo con la maschera.
Added lines 44-61:
* %green% '''Specificare la sequenza di eventi quando una macchina manda il pacchetto al proprio indirizzo di rete o al loop'''
Se lo manda all'indirizzo di rete crea un vero e proprio frame ethernet, lo scrive sul filo e se lo manda.
Se manda un pacchetto al loop fa una copia del pacchetto memoria su memoria, il pacchetto quindi in realtà non passa mai per la rete.

* %green% '''Quali sono le condizioni di integrità sul pacchetto?'''
IL pacchetto che ci sta in un frame ethernet deve starci anche in un frame di una rete diversa, altrimenti le due reti non possono comunicare. Per fare in modo che ciò avvenga il frame della rete più piccola deve essere grosso almeno quanto l'header IP dell'altra, altrimenti non sarà possibile trasmettre nessun payload.

* %green% '''Differenze UDP e TCP?'''
UDP fornisce un servizio inaffidabile e non orientato alla connessione. La sua unica funzione è quella del multiplexing
TCP fornisce un servizio affidabile e orientato alla connessione. Funzioni:
° controllo di flusso end to end
° controllo di congestione end to end
° ritrasmissione di PDU persi o corrotti
° consegna nella corretta sequenza delle unità dati

* %green% '''Differenze banda nominale banda reale'''
La banda nominale è quella che mi viene data, cioè quella che potrei effettivamente usare, mentre quella reale è quella che uso, togliendo cioè l'overhead.
Changed line 25 from:
* %green% '''Che diff. c'è tra DHCP e ARP?'''%%\\
to:
* %green% '''Che differenza c'è tra DHCP e ARP?'''%%
Added lines 40-43:

* %green% '''Come si calcola la checksum dell'header IP se essa stessa ne fa parte?'''%%\\
Perché non tiene conto del campo somma, che fissa a 0.
Changed lines 39-41 from:
Perchè il ricevente deve tenere nel buffer tutti i pacchetti inviati (è oneroso); potrà eliminarli solo quando avrà ricevuto l'ack di ogni pacchetto che ha inviato.
to:
Perchè il ricevente deve tenere nel buffer tutti i pacchetti inviati (è oneroso).
Changed lines 26-28 from:
**DHCP assegna dinamicamente gli indirizzi IP;
**ARP invece serve per far costruire agli host delle tabelle in cui si associano indirizzi IP e MAC.
to:
** DHCP assegna dinamicamente gli indirizzi IP;
** ARP invece serve per far costruire agli host delle tabelle in cui si associano indirizzi IP e MAC.
Changed lines 31-34 from:
**dell'indirizzo;
**della maschera di sottorete;
**del gateway.
to:
** dell'indirizzo;
** della maschera di sottorete;
** del gateway.
Added lines 25-41:
* %green% '''Che diff. c'è tra DHCP e ARP?'''%%\\
**DHCP assegna dinamicamente gli indirizzi IP;
**ARP invece serve per far costruire agli host delle tabelle in cui si associano indirizzi IP e MAC.

* %green% '''Di cosa ho bisogno per andare sulla rete?'''%%\\
Ho bisogno:
**dell'indirizzo;
**della maschera di sottorete;
**del gateway.

* %green% '''Come faccio a sapere se l'instradamento è diretto o indiretto?'''%%\\
Facendo il test del prefisso.

* %green% '''Perchè con selective repeat è difficile mantenere l'astrazione del canale FIFO?'''%%\\
Perchè il ricevente deve tenere nel buffer tutti i pacchetti inviati (è oneroso); potrà eliminarli solo quando avrà ricevuto l'ack di ogni pacchetto che ha inviato.
Changed lines 22-24 from:
** diminuire il TTL (Time To Live). Ad esempio scegliamo 16 bit per il TTL. Inviamo il pacchetto sulla rete e ad ogni router che passa il TTL viene toglie 1 bit.
->Quando TTL = 0 il pacchetto viene droppato (eliminato)
to:
** diminuire il TTL (Time To Live). Ad esempio scegliamo 16 bit per il TTL. Inviamo il pacchetto sulla rete e ad ogni router che passa il TTL viene toglie 1 bit.\\
Quando TTL = 0 il pacchetto viene droppato (eliminato)
Changed lines 23-24 from:
Quando TTL = 0 il pacchetto viene droppato (eliminato)
to:
->Quando TTL = 0 il pacchetto viene droppato (eliminato)
Changed line 22 from:
** diminuire il TTL (Time To Live). Ad esempio scegliamo 16 bit per il TTL. Inviamo il pacchetto sulla rete e ad ogni router che passa il TTL viene toglie 1 bit.\\
to:
** diminuire il TTL (Time To Live). Ad esempio scegliamo 16 bit per il TTL. Inviamo il pacchetto sulla rete e ad ogni router che passa il TTL viene toglie 1 bit.
Added lines 2-4:
[[Torna alla pagina di Sistemi Anticoncezionali delle Reti e dei Damiani->Sistemi]]
----
Changed lines 6-27 from:
* %green% '''Perchè fli errori nella telefonia vengono tollerati mentre nei dati no?'''\\
%black%
Un bit errato nella trasmissione voce può far sentre male la voce stessa o presentare rumori di sottofondo ma comunque si capisce lo stesso!\\
Se
invece il bit errtto è quello di un programma l'esecuzione dello stesso uò dare problemi e nei casi peggiori mandare il progarmma in CRASH.\\
\\

* %green% '''Nell'uso dei protocolli MAC, la banda influenza il rischio di collisione?'''\\
%black%
Si, più è grande la banda e minore è il rischio di collisione. Poi se la mia è una superbanda posso anche tenere il protocollo ALOHA.\\

* %green% '''Può capitare che il Gateway G debba fare più che cambiare lo header per consegnare un pacchetto su una Ethernet diversa da quella del destinatario?'''\\
%black%
Si perchè mittente e destinatario non essendo sulla stessa ethernet( ad esempio una è ARP el'altra ATM che è molto maggiore rispetto la prima), il gateway deve frammenatre il pacchetto.\\
\\

* %green% '''RANDOM, FLOODING e HOT POTATO : quali di queste tecniche di instradamento basati su tabelle garantisce il recapito del pacchetto? '''\\
%black%
Se la rete è molto connessa va bene FLOODING e RANDOM ( tutte le strade portano a Roma). HOT POTATO è il meno efficiente\\
\\

* %green% '''Quali modifiche può fare un router su un pacchetto?'''\\
%black%
to:
* %green% '''Perchè gli errori nella telefonia vengono tollerati mentre nei dati no?'''%%\\
Un bit errato nella trasmissione voce può far sentre male la voce stessa o presentare rumori di sottofondo ma comunque si capisce lo stesso! Se invece il bit errato è quello di un programma l'esecuzione dello stesso uò dare problemi e nei casi peggiori mandare il progarmma in CRASH.

* %green% '''Nell'uso dei protocolli MAC, la banda influenza il rischio di collisione?'''%%\\
Si, più è grande la banda e minore è il rischio di collisione. Poi se la mia è una superbanda posso anche tenere il protocollo ALOHA.

* %green% '''Può capitare che il Gateway G debba fare più che cambiare lo header per consegnare un pacchetto su una Ethernet diversa da quella del destinatario?'''%%\\
Si perchè mittente e destinatario non essendo sulla stessa ethernet( ad esempio una è ARP el'altra ATM che è molto maggiore rispetto la prima), il gateway deve frammentare il pacchetto.

* %green% '''RANDOM, FLOODING e HOT POTATO : quali di queste tecniche di instradamento basati su tabelle garantisce il recapito del pacchetto? '''%%\\
Se la rete è molto connessa va bene FLOODING e RANDOM ( tutte le strade portano a Roma). HOT POTATO è il meno efficiente.

* %green% '''Quali modifiche può fare un router su un pacchetto?'''%%\\
Changed lines 21-22 from:
* modificare il flag di deframmentazione nel caso in cui il pacchetto debba essere frammentato
* diminuire il TTL (Time To Live). Ad esempio scegliamo 16 bit per il TTL. Inviamo il pacchetto sulla rete e ad ogni router che passa il TTL viene toglie 1 bit.\\
to:
** modificare il flag di deframmentazione nel caso in cui il pacchetto debba essere frammentato
** diminuire il TTL (Time To Live). Ad esempio scegliamo 16 bit per il TTL. Inviamo il pacchetto sulla rete e ad ogni router che passa il TTL viene toglie 1 bit.\\
Changed lines 25-26 from:
to:
----
[[Torna alla pagina di Sistemi Anticoncezionali delle Reti e dei Damiani->Sistemi]]
November 01, 2007, at 12:18 PM by Gruppo studio SMOBILIA -
Added lines 1-31:
(:title Domande Damiani:)
%titolo%''':: Domande Damiani ::'''
* %green% '''Perchè fli errori nella telefonia vengono tollerati mentre nei dati no?'''\\
%black%
Un bit errato nella trasmissione voce può far sentre male la voce stessa o presentare rumori di sottofondo ma comunque si capisce lo stesso!\\
Se invece il bit errtto è quello di un programma l'esecuzione dello stesso uò dare problemi e nei casi peggiori mandare il progarmma in CRASH.\\
\\

* %green% '''Nell'uso dei protocolli MAC, la banda influenza il rischio di collisione?'''\\
%black%
Si, più è grande la banda e minore è il rischio di collisione. Poi se la mia è una superbanda posso anche tenere il protocollo ALOHA.\\

* %green% '''Può capitare che il Gateway G debba fare più che cambiare lo header per consegnare un pacchetto su una Ethernet diversa da quella del destinatario?'''\\
%black%
Si perchè mittente e destinatario non essendo sulla stessa ethernet( ad esempio una è ARP el'altra ATM che è molto maggiore rispetto la prima), il gateway deve frammenatre il pacchetto.\\
\\

* %green% '''RANDOM, FLOODING e HOT POTATO : quali di queste tecniche di instradamento basati su tabelle garantisce il recapito del pacchetto? '''\\
%black%
Se la rete è molto connessa va bene FLOODING e RANDOM ( tutte le strade portano a Roma). HOT POTATO è il meno efficiente\\
\\

* %green% '''Quali modifiche può fare un router su un pacchetto?'''\\
%black%
Il router può operare in due direzioni:
* modificare il flag di deframmentazione nel caso in cui il pacchetto debba essere frammentato
* diminuire il TTL (Time To Live). Ad esempio scegliamo 16 bit per il TTL. Inviamo il pacchetto sulla rete e ad ogni router che passa il TTL viene toglie 1 bit.\\
Quando TTL = 0 il pacchetto viene droppato (eliminato)