 | |
Il progetto dsy.it è l'unofficial support site dei corsi di laurea del Dipartimento di Scienze dell'Informazione e del Dipartimento di Informatica e Comunicazione della Statale di Milano. E' un servizio degli studenti per gli studenti, curato in modo no-profit da un gruppo di essi. I nostri servizi comprendono aree di discussione per ogni Corso di Laurea, un'area download per lo scambio file, una raccolta di link e un motore di ricerca, il supporto agli studenti lavoratori, il forum hosting per Professori e studenti, i blog, e molto altro...
In questa sezione è indicizzato in textonly il contenuto del nostro forum |
[ESAME] Svolgimento vecchi temi
Clicca QUI per vedere il messaggio nel forum |
| futurbaggio |
Svolgimento tema d'esame del 02 febbraio 2004
1)Nel primo caso (cioè i pacchetti inviati sono, in ordine, AB1 BC AB2):
- il nodo A invia il pacchetto AB1 al bridge;
- viene aggiornata la tabella di forwarding con l'indirizzo MAC del nodo A e il numero d'interfaccia del bridge a cui è collegato;
- viene poi effettuato un flooding in quanto nella tabella di forwarding del bridge non c'è alcun riferimento al nodo B;
- il nodo B invia al bridge il pacchetto BC;
- viene aggiornata la tabella di forwarding con l'indirizzo MAC del nodo B e il numero d'inferfaccia del bridge a cui è collegato;
- viene poi effettuato un flooding in quanto nella tabella di forwarding del bridge non c'è alcun riferimento al nodo C;
- il nodo A invia al bridge il pacchetto AB2;
- nella tabella di bridge è registrato già il numero di interfaccia a cui il nodo B è collegato, quindi il pacchetto viene inoltrato direttamente.
Nel secondo caso (cioè i pacchetti inviati sono, in ordine, AB1 CB AB2):
- il nodo A invia il pacchetto AB1 al bridge;
- viene aggiornata la tabella di forwarding con l'indirizzo MAC del nodo A e il numero d'interfaccia del bridge a cui è collegato;
- viene poi effettuato un flooding in quanto nella tabella di forwarding del bridge non c'è alcun riferimento al nodo B;
- il nodo C invia al bridge il pacchetto CB;
- viene aggiornata la tabella di forwarding con l'indirizzo MAC del nodo C e il numero d'inferfaccia del bridge a cui è collegato;
- viene poi effettuato un flooding in quanto nella tabella di forwarding del bridge non c'è alcun riferimento al nodo B;
- il nodo A invia al bridge il pacchetto AB2;
- viene effettuato un flooding in quanto nella tabella di forwarding del bridge non c'è alcun riferimento al nodo B.
2)Le condizioni necessarie affinchè le comunicazioni possano avvenire sono:
- l'interfaccia FW deve avere un IP pubblico o cmq devono esistere meccanismi (vedi port forwarding) per renderla raggiungibile da Internet;
- sulla porta 4000 dell'interfaccia FW deve essere in ascolto una ServerSocket;
- la porta locale 4001 dell'interfaccia TI non deve essere utilizzata da un'altra applicazione.
Un pacchetto IP viene inviato dall'interfaccia TI e buttato su Internet, attraversa uno o più router e poi viene inoltrato all'interfaccia FW.
NB: nn ho capito molto bene cosa gfp intendesse per “segmenti TCP relativi alla connessione che ne viene instaurata”. Suggerimenti?
3)Trattandosi di un server multithread la gestione delle richieste viene completamente delegata ai singoli thread, a ciascuno dei quali è associata una “socket di servizio”, attiva su una porta diversa dalla porta P del processo padre. Quindi dalla richiesta di C1 alla risposta del server a C2 passano esattamente 4 secondi, uno che distanzia le richieste dei due client e tre di attesa nel thread come definito da protocollo.
Qualora, a condizioni invariate di tempo e protocollo, le richieste fossere rivolte a porte distinte, P1 e P2, la situazione non cambierebbe, perchè come abbiamo visto le richieste vengono difatto svolte da “socket di servizio” distinte tra loro e dalla porta P.
4)E' falso dire che la probabilità di collisioni è superiore per velocità minori di propagazione del segnale nel mezzo trasmissivo, per la relazione che specifica l'efficienza di Ethernet abbiamo:
Efficienza = 1 / (1 + 5Tprop/Ttrans)
Con Tprop uguale al tempo necessario per la propagazione del segnale tra due qualsiasi nodi e Ttrans il tempo necessario per la trasmissione del massimo frame Ethernet inviabile.
Come si vede facilmente l'efficienza tende a 1 per valori sempre più piccoli di Tprop (tempo di propagazione), ovviamente velocità di propagazione e tempo di propagazione sono inversamente proporzionali tra loro quindi per valori massimi di efficienza (quindi tempo di propagazione tendente a zero) sono necessari valori massimi di velocità di propagazione del segnale.
Aspetto risposte e correzioni
Roberto |
| futurbaggio |
Svolgimento tema d'esame del 23 febbraio 2004
1)I frame MAC di broadcast inviati da LANA1 vengono ricevuti da tutti i nodi che compongono la LANA, per definizione infatti il dominio di broadcast si individua eliminando i dispositivi di livello 3 (o superiori). Non esiste comunque alcun modo, lavorando esclusivamente a livello data-link (quindi con frame MAC), di poter raggiungere con un frame MAC i nodi che compongono la LANB, non esiste infatti alcuna relazione (a livello data-link) tra i due adattatori che compongono il router e ci permetterebbero di entrare in comunicazione con la LANB. L'unico modo per consentire ad un frame MAC di broadcast di raggiungere tutte le macchine elencate nel testo dell'esercizio è sostituire il router con un bridge.
2)Molto simile ad un esercizio del precedente tema d'esame, non bisogna farsi ingannare dal fatto che si usi due volte la porta 4000, essendo due interfacce differenti non condividono lo stesso stack di porte.
3)UDP è per definizione un protocollo non affidabile, non dispone cioè di una serie di servizi e controlli che garantiscano che il pacchetto arrivi a destinazione o tanto meno che sia rispettato l'ordine di arrivo (rispetto a quello di invio). Si potrebbe quindi supporre che, dato che ogni datagramma UDP potrebbe percorre un path distinto, il primo pacchetto inviato abbia trovato una congestione su un router mentre il secondo pacchetto, più fortunato, è riuscito ad arrivare più velocemente a destinazione. Per risolvere questo problema si potrebbe impedire l'invio del pacchetto A2 fino a che non viene confermato, lato client, l'arrivo del pacchetto A1.
4)Vedi l'esercizio 4 del precedente tema d'esame, qui si fa riferimento al diametro temporale e non alla velocità di propagazione ma ragionando ci si arriva facilmente: più piccolo è il diametro temporale (ritardo di propagazione) meno probabilità di collisioni saranno presenti. |
| GinoPilotino |
| a questo ragazzo bisognerebbe fare un monumento. :D |
| Flavia |
Off-Topic:
Ma un bridge in pratica si comporta come un router?Ovvero, se un bridge ha 3 porte, avrà 3 indirizzi IP, 3 indirizzi MAC etc etc...? |
| futurbaggio |
Originally posted by Flavia
Off-Topic:
Ma un bridge in pratica si comporta come un router?Ovvero, se un bridge ha 3 porte, avrà 3 indirizzi IP, 3 indirizzi MAC etc etc...?
Il bridge non ha indirizzi IP, semplicemente perchè non ha la minima idea di cosa siano IP o qualsiasi altro protocollo di livello 3.
Roberto |
| Flavia |
Quindi????
Come si comporta se arriva/manda un pacchetto?
Non trovo il bridge sul libro di testo.. |
| futurbaggio |
Originally posted by Flavia
Quindi????
Come si comporta se arriva/manda un pacchetto?
Non trovo il bridge sul libro di testo..
Bridge alias Switch, sono nel capitolo del Link Layer... non farti fregare :twisted:
Per come si comporta ti rimando al libro, è spiegato + che bene
Roberto |
| Flavia |
Ahhhhhhhhhhhhh!Bridge=switch! :D
Grazie! |
| internato |
Grande futur.......altri temi d'esame svolti????
io ho fatto:
Esame 6-12-04
1)
L’algoritmo spanning tree fa in modo che pacchetti inviati in broadcast da ognuno dei nodi non arrivi duplicato agli altri nodi. Es., se S1 invia in broadcast un pacchetto, esso arriverà, secondo un ipotetico Spanning Tree, dal brinde B1 al bridge B2 direttamente, mentre al bridge B3 arriverà attraverso il router R, facendo in modo che S3 non riceva il pacchetto anche attraverso il canale diretto con S1.
3)
NON SI POSSONO DEDURRE INFORMAZIONI SULLA RELAZIONE TRA T1 E T2. ESSI POSSONO ESSERE UGUALI O DIFFERENTI, AVENDO SEGUITO OGNUNO ROTTE DIFFERENTI PER ARRIVARE DALLA STAZIONE IPn ALLA STAZIONE IP0
Esame 13-7-04
3)
PUO’ TRATTARSI SEMPLICEMENTE DI UN RITARDO O DI UN ROUTING DIVERSO SEGUITO DA UN PACCHETTO, E NON NECESSARIAMENTE DI UNA PERDITA. COI RITARDI ACCUMULATI DA ALCUNI PACCHETTI NELLE RETI CHE EVENTUALMENTE ATTRAVERSANO, E’ POSSIBILE CHE LA SEQUENZA DI ARRIVO PRESENTI DELLE LACUNE, LE QUALI PERO’ NON SIGNIFICANO PER FORZA CHE IL PACCHETTO E’ ANDATO PERSO
Esame 15-5-04
3)
I PACCHETTI UDP NON HANNO SEQUENCE NUMBER PER GESTIONE DEL FLUSSO
Esame 18-6-04
3)
NON E’ DETTO CHE I TTL SIANO DIFFERENTI, ANZI E’ PIU’ PROBABILE CHE SIANO UGUALI. OGNI VOLTA CHE UN PACCHETTO ARRIVA AD UNA STAZIONE, QUEST’ULTIMA INVIA UN NUOVO PACCHETTO ALLA STAZIONE SUCCESSIVA, CON TTL CHE PUO’ ESSERE UGUALE O DIVERSO DAL TTL DEL PACCHETTO RICEVUTO. NON SI TRATTA DELLO STESSO PACCHETTO CHE GIRA!!
Esame 23-2-04
3)
E’ NECESSARIO USARE UN PROTOCOLLO CHE SFRUTTI TCP. UDP, INFATTI, NON GESTISCE E NON GARANTISCE IL CORRETTO FLUSSO DEI DATI ED E’ NORMALE CHE SUCCEDANO FENOMENI COME QUELLO PRESENTATO.
Esame 23-09-04
3)
LA RETE E’ DI TIPO DATAGRAM, OVVERO LA ROTTA CHE OGNI PACCHETTO INTRAPRENDE E’ DIVERSA OGNI VOLTA. TRA LE STAZIONI CHE PARTECIPANO AL PROTOCOLLO NON E’ DETTO CHE CI SIA PERFORZA UN COLLEGAMENTO FISICO DIRETTO, MA E’ POSSIBILE CHE TRA ESSE INTERCORRANO ALTRE STAZIONI O ADDIRITTURA ALTRE RETI CON RELATIVI ROUTER, BRIDGE…..QUINDI SE LA RICEZ DEL PACCHETTO 2n+2 E’ RITARDATA E’ PERCHE’ QUEST’ULTIMO, RISPETTO AL PACCHETTO n HA SEGUITO UNA STRADA DIVERSA.
SE IL PRIMO PACCHETTO UDP RICEVUTO DA IP0 ARRIVA DOPO UN TEMPO T, E SE IL SECONDO PACCHETTO INVIATO IMPIEGA UNA STRADA Più CORTA E’ POSSIBILE CHE QUEST’ULTIMO ARRIVI PRIMA.
Esame 27-03-04
3)
E’ POSSIBILE CHE LA SEQUENZA TTL DI UN PACCHETTO IN VIAGGIO SI AZZERI, MA NON PERCHE’ E’ LOGICO CHE PRIMA O POI SI AZZERI (OGNI STAZIONE INVIA UN NUOVO PACCHETTO CON NUOVO TTL), MA PERCHE’ E’ POSSIBILE CHE NEL TRAGITTO DA UNA STAZIONE ALL’ALTRA VENGA INSTRADATO VERSO ALTRE RETI IL CUI NUMERO DI HOP ELEVATO FA AZZERARE IL TTL E FACCIA SMARRIRE IL PACCHETTO STESSO
Insultatemi pure se lo ritenete opportuno...
ah, futur hai fatto la domanda 4 del tema d'esame del 6-12-04...nn capisco neanche la richiesta!!!! Domini di collisione? domini di broadcast??????
grazie |
| No?Ya! |
Scusate ma oggi ho il cervello miope :bolted: ...
qualcuno mi sa dire dove trovare i vecchi esercizi / temi d'esame? Ho fatto una ricerca sul sito di gfp ma mi son perso tra i caratteri e link bluetto...
... ATTENZIONE! UN'ESPOSIZIONE PROLUNGATA A KUROSE/ROSS PUO' ALTERARE ALCUNE FUNZIONI VITALI DEL TUO CORPO!!! |
| GinoPilotino |
ho provato a risolvere l'esame del 27-marzo-04
controllate molto bene perchè posso aver scritto mooolte crastonerie.
Esercizio 1
abbiamo due lan, ogni lan è composta da 2 host e da un hub che ha 3 interfacce: con due porte comunica con gli host mentre con la terza comunica con un bridge.
chiameremo lanA la lan composta da A1, A2, hubA e collegata alla porta del bridge A e lanB la lan composta da B1, B2, hubB e collegata alla porta B dello switch.
ora, da quanto ho capito i singoli host implementano l'algoritmo csma, l'hub no, il bridge si.
all'inizio nessuno è in fase di comunicazione e tutti i link sono liberi.
l'host A1 della lan A vuole comunicare unicast con l'host B1 della lanB, l'interfaccia dell'host attraverso l'algoritmo csma controlla che non ci siano altri host che stanno comunicando e poichè il canale è libero invia il pacchetto.
il pacchetto giunge all'hub che lo invia verso A2 e verso la porta A dello switch.
lo switch appena riceve i primi bytes del pacchetto, poichè la porta B è libera in quanto non vi sono segni di comunicazione, come da metodo cut-through inizia immediatamente ad inviare i bytes nella porta B.
questi bytes del pacchetto appena giungono hub B vengono dirottati sia verso B1 che verso B2 nonostante la comunicazione sia unicast (nel caso specifico l'host non interessato, ossia B1 scarterebbe il pacchetto ricevuto).
il problema sta nel fatto che B2, prima di ricevere questi bytes dall'hub decide di comunicare con B1, e poichè la porta di B2 controlla la rete e non rileva traffico comincia ad inviare il pacchetto.
sinceramente da qua in poi non ho ben capito come si svolge la cosa.
a) se i bytes inviati da port B arriva all'hub B e vengono smistati da questo sia su B1 che su B2 prima che allo stesso hub arrivino i dati inviati da B2, è la porta dell'host B2 a rilevare la collisione e si ferma lasciando indisturbata la comunicazione tra port B e B1?
b) se invice i bytes inviati da B2 giungono all'hub B prima che giungano quelli da port B dello switch, a rilevare la collisione e quindi a fermarsi è la porta B dello switch?
illuminatemi.
L'ultima domanda dell'esercizio invece dovrebbe essere così: A1 ha inviato il pacchetto verso l'hub A, che lo ha inoltrato ad A2 e a port A nello switch.
ora il pacchetto giunto allo switch viene gestito da quest'ultimo e nella lan A se A2 invia un frame ad A1 prima che B1 riceva il pacchetto di A1 non ci sono comunque collisioni nel dominio lan A.
Esercizio 2
In a metto l'indirizzo remoto che, nel nostro caso è uguale a quello locale; l'interfaccia di rete a quanto pare è unica e di conseguenza bisognerebbe avere sulla stessa interfaccia:
- una socket in ascolto sulla porta 4000;
- un'altra socket sempre sulla porta 4000 creando un conflitto
per funzionare la seconda istruzione dovrebbe avere una porta remota diversa da quella locale, ossia due socket con porte diverse sulla stessa interfaccia.
Esercizio 3
Nel terzo esercizio, il TTL è un valore processato dai router, ossia da nodi dotati di layer 3.
Ad ogni passaggio tramite un router il TTL viene decrementato di una unita.
Un pacchetto terminrebbe di rimbalzare qualora il numero di router che deve passare il pacchetto per giungere a destinazione è maggiore del TTL impostato dall'host mittente.
Esercizio 4
qui sono molto incerto; ogni host è collegato con un canale diretto, quindi full duplex con lo switch.
Non essendoci mai collisioni all'interno della rete poichè vengono utilizzati canali distinti per invio e ricezioni dati da host e switch e viceversa, a parte una possibile coda che alcuni frame possono trovare alle porte dello switch non sfruttano sempre la piena banda? |
| internato |
Anch'io ho perplessità sulla domanda 4 del 23-3-2004
Il fatto è che se A e B trasmettono contemporaneamente verso C, non ci sono problemi per quanto riguarda l'arrivo al bridge, ma poi, affinchè i frame vengano recapitati a C, come fanno a trasmettere contemporaneamente? Uno dei due, per il protocollo CSMA/CD deve aspettare che finisca la trasmissione dell'altro, no?? |
| internato |
Esame 13-7-04
1)
Dalla S1 parte un frame con MAC1 - MACR1 e IP1 – IP2
A S2 arriva un frame con MACR2 – MAC2 e IP1 – IP2
Da S2 parte un frame con MAC2 – MACR2 e IP2 – IP1
A S1 arriva un frame con MACR1 – MAC1 e IP2 – IP1
La stazione S3 non riceve alcun frame in flooding dal bridge B, dato che esso passa prima per il router R3 il quale, cedendo che la destinazione non è tra le stazioni a cui è collegato, scarta il frame.
Esame 15-5-04
1)
Tree 1 – Da R a B1 e da B1 a B2
Tree 2 – Da R a B2 e da B2 a B1
4)
Le stazioni trasmettono senza problemi sul canale full-duplex che li collega al bridge. Quando, invece, è il bridge a dover inviare loro una trama, deve rispettare il protocollo CSMA/CD per il quale bisogna attendere che il canale sia libero da connessioni per poter inoltrare il frame. In ricezione è logico quindi un ritardo dei frame in arrivo dal bridge. Sempre secondo il protocollo CSMA/CD, ogni volta che un frame collide nel canale, aspetta sempre più tempo per poter essere poi ritrasmesso, causando, così, gravi ritardi nell’invio di frame dal bridge.
GinoPilotino, anche gli host devono rispettare il CSMA/CD?Se si la mia soluz è sbagliata!
Esame 18-6-04
1)
S1 crea datagram IP con IP sorgente IP1 e IP destin IP2, e lo incapsula in un frame con MAC destinaz. MAC2
B1 inoltra il frame al router R1.
R1 estrae il datagram IP dal frame e vede che è destinato a S2, e lo inoltra a R2
R2 riconosce IP2 nella LAN di B2 e invia a quest’ultimo un frame contenente MAC2 come destinazione.
B1 inoltra il frame a S2.
4)
A breve la rete riuscirà ad avere velocità più basse rispetto a quelle auspicate coi collegamenti e le porte a 100Mbps. Infatti i collegamenti a 20Mbps verranno frenati una volta arrivati i dati ai bridge, i quali possono trasmettere, per ogni direzione a 10Mbps, quindi a velocità dimezzata. Se poi, data la velocità maggiore dei dati in arrivo dalle stazioni, i pacchetti dovessero accodarsi nei bridge in attesa di essere inoltrati, ci sarebbe la possibilità di perdita di questi pacchetti.
Prego insultatemi nuovamente!!! |
| internato |
Scusate ma i dubbi e le perplessità mi attanagliano la mente....sto fondendo......ho dei chiarimenti da chiedervi:
che differenza c'è tra domini broadcast e domini di collisione (ci sono molte domande nei temi d'esame che ne richiedono la conoscenza)
poi, il canale nel quale è istanziato il protocollo CSMA/CD è quello che va dalla porta del bridge alla singola stazione? o anche viceversa?
Vi prego aiutatemi......sto impazzendo!!!! |
| GinoPilotino |
| se ad uno switch sono collegati host con link diretti in full duplex non è necessaria l'implementazione dell'algoritmo CSMA! |
| GinoPilotino |
Originally posted by internato
Anch'io ho perplessità sulla domanda 4 del 23-3-2004
Il fatto è che se A e B trasmettono contemporaneamente verso C, non ci sono problemi per quanto riguarda l'arrivo al bridge, ma poi, affinchè i frame vengano recapitati a C, come fanno a trasmettere contemporaneamente? Uno dei due, per il protocollo CSMA/CD deve aspettare che finisca la trasmissione dell'altro, no??
no, non viene utilizzato l'algoritmo CSMA...aspettano solo nel buffer di output della porta d'uscita se è utilizzata da un altro frame. (credo :D) |
| internato |
Per quanto riguarda la domanda 4 del 27-3-04 hai ragione tu Gino....l'unico rallentamento è dato dalla coda che eventualmente si va a formare nel buffer della porta di output del bridge verso C. Ma la coda in questo buffer non è gestita col protocollo CSMA/CD??? O sto facendo un sacco di confusione?
Il discorso è uguale per l'eserc 4 del 15-5-04, che dice:
Si consideri una rete IEEE 802.3 (Ethernet) realizzata mediante un bridge dotato di tre sole porte identiche, configurate in modalità full-duplex, alle quali sono rispettivamente collegate le stazioni A, B e C. Sia il bridge che le stazioni sono in grado di reggere indefinitamente a lungo una trasmissione/ricezione di trame a wire-speed (il bridge su tutte e tre le proprie porte contemporaneamente). La stazione A trasmette esclusivamente alla stazione B, la stazione B trasmette esclusivamente alla stazione C, e quest’ultima trasmette esclusivamente alla stazione A. Le trame sono tutte di lunghezza pari a quella massima ammessa da IEEE 802.3 (e presentano quindi un payload di 1500 byte per ciascuna trama). Il payload complessivo per unità di tempo dovrebbe quindi essere pari a 1500*N byte/sec, dove N è il numero di trame di lunghezza massima che possono essere trasmesse/ricevute (a wire-speed) in un secondo su ciascuna porta. Tuttavia, le stazioni si accorgono che nel lungo periodo, pur in totale assenza di malfunzionamenti degli apparati, il payload misurato in trasmissione è effettivamente pari al valore massimo teorico 1500*N, mentre il payload misurato in ricezione è leggermente inferiore a questo valore. Si dia una spiegazione di questo curioso fenomeno, e si discuta a quali conseguenze esso potrà portare, trascorso un intervallo di tempo sufficientemente lungo.
Qui il discorso è che i canali full duplex funzionano correttamente e alla giusta velocità quando le stazioni trasmettono, in ricezione, invece, si forma la solita ed eventuale coda nel buffer della porta di uscita verso ogni stazione, giusto?
Mannaggia al CSMA/CD!!!!! |
| GinoPilotino |
eh si da quanto ho capito io dovrebbe essere così.
io ho inteso dal libro che gli algoritmi CSMA vengono utilizzati dalle porte SOLO del bridge e degli host ma non dagli hub quando questi nodi sono collegati in modo classico, mentre non viene implementato l'algoritmo CSMA dalle porte di bridge e host quando sono collegati in modo diretto, ossia full duplex.
il problema è però un altro; nell'esercizio 1 che ho svolto io del tema d'esame del 27-3 come cavolo funziona la storia della collisione??? |
| No?Ya! |
Originally posted by internato
Esame 18-6-04
4)
[...] i quali possono trasmettere, per ogni direzione a 10Mbps, quindi a velocità dimezzata. [...]
Io ho un po' di dubbi su questa domanda ... nel senso il fatto che un collegamento sia a 10Mbps full duplex, vuol dire che può trasmettere/ricevere contemporaneamente a 10mbps o per il fatto che trasmette e riceve contemporaneamente allora va a 5mbps? Perchè se così fosse la risposta sarebbe diversa... |
| internato |
| a dire la verità anch'io ho questo dubbio.... |
| internato |
quindi se il collegamento diretto bridge-stazione è full duplex non si applica CSMA/CD?
E quando cavolo si applica sto CSMA/CD????
sapete anche fare percaso la domanda 2 del 6-12-04....gino, ke dici? |
| GinoPilotino |
| trasmette a 10 e riceve a 10 |
| internato |
| ah si? e allora in quell'eserc non ci sono ritardi o cose simili... |
| Flavia |
Originally posted by internato
quindi se il collegamento diretto bridge-stazione è full duplex non si applica CSMA/CD?
E quando cavolo si applica sto CSMA/CD????
sapete anche fare percaso la domanda 2 del 6-12-04....gino, ke dici?
Penso si applichi quando non c'è il full-duplex. Ovvero (penso) che se c'è full-dulpex non ci sia problema di collisione tra un pacchetto che mi sta arrivando e uno che sto inviando. Serve solo quando in un canale arrivano frame da più farti e poi si debba decidere come "regolare" la trasmissione!
Non si usa nell'Ethernet sto cavolo di CSMA/CD?????
Quello che ho detto potrebbe essere totalmente falso! :D
Anche io sto fondendo! Però sappiate che io mi baserà sulle vostre correzioni qua postate, quindi vi conviene che siano giuste! :D |
| GinoPilotino |
bella domanda...
innanzi tutto credo sia giusto dire che se creo una serversocket in localhost non posso creare una socket sulla stessa interfaccia con lo stesso numero di porta, quindi il numero di porta di c deve essere diverso da 4000.
il problema è che qua bisogna chiedersi, che strada fa il pacchetto?
suppongo che il valore della subnet sia importante, perchè indica l'indirizzo ip dell'host appartenente ad una certa sottorete.
da quanto ho capito io un indirizzo tipo
215.114.153.124/24 è ben diverso da 215.114.153.124/23.
Quindi, [molto forse] se indico come subnet la mia stessa subnet il pacchetto mi torna indietro altrimenti no e verrà inoltrata dai router verso chi ha il mio stesso Ip ma con subnet diversa. |
| Flavia |
Originally posted by GinoPilotino
da quanto ho capito io un indirizzo tipo
215.114.153.124/24 è ben diverso da 215.114.153.124/23.
Quindi, [molto forse] se indico come subnet la mia stessa subnet il pacchetto mi torna indietro altrimenti no e verrà inoltrata dai router verso chi ha il mio stesso Ip ma con subnet diversa.
Secondo me non sono diversi questi indirizzi!Anzi, non possono nemmeno coesistere!Perchè comunque gli Ip sono globalmente unici, quindi il fatot che tenga fissati i primi 23 o 24 bit non toglie la condizione che poi debbano essere unici!
No?
:?
Qua mancano le conferme di Futur! |
| GinoPilotino |
| ma gli IP non devono essere unici solo all'interno della proprio subnet? |
| Flavia |
Originally posted by GinoPilotino
ma gli IP non devono essere unici solo all'interno della proprio subnet?
Si ma se vengono univocamente assegnati degli stack di indirizzi, uno stesso prefisso non può essere assegnato a due organizzazioni diverse.. |
| internato |
secondo me sull'esercizio 2 del 6-12-05 bisogna dire che:
- l'interfaccia remota della socket C è uguale all'interfaccia locale della ServeSocket S, avendo lo stesso indirizzo IP. Avendo anche lo stesso numero di porta, le due socket in questo modo non possono coesistere
- se l'indirizzo IP di tale interfaccia lo si vuole cercare per nome, visto che è utilizzato il metodo getByName, il nome dell'interfaccia deve essere uguale all'indirizzo stesso, dato che il nome che è usato per cercare l'IP è "159.149.130.1", no?
e comunque sto delirando.....
FUTUR, AIUTACI TUUUUUUUU!!!!!!!!!!!!!!!!!!!!!!!!! |
| internato |
| ma soprattutto, cos'è la netmask? |
| GinoPilotino |
Originally posted by internato
ma soprattutto, cos'è la netmask?
perfetto :D |
| Flavia |
Originally posted by internato
ma soprattutto, cos'è la netmask?
Non è mica l'ultima parte di un indirizzo IP, che identifica univocamente un nodo?
Cioè, se tu hai 111.111.111.111/24 tu hai che i primi 24 bit indicano la LAN specifica e gli ultimi 8 (submask) servono per denotare i possibili 256 nodi!
No?
:? |
| GinoPilotino |
| ma qui siamo sempre in una decina a postare sul forum...o noi siamo particolarmente ignoranti e deficienti oppure cosa? :? |
| GinoPilotino |
Originally posted by GinoPilotino
bella domanda...
innanzi tutto credo sia giusto dire che se creo una serversocket in localhost non posso creare una socket sulla stessa interfaccia con lo stesso numero di porta, quindi il numero di porta di c deve essere diverso da 4000.
mi sa che ho detto una cavolata, perchè creando la seconda socket dovrebbe essere assegnato dal sistema un indirizzo di porta logica diverso dal 4000 |
| WaLkYrIuS |
Originally posted by GinoPilotino
ma qui siamo sempre in una decina a postare sul forum...o noi siamo particolarmente ignoranti e deficienti oppure cosa? :?
mi sa che siete gli unici che ci capite qualcosa...:cry: |
| futurbaggio |
Originally posted by GinoPilotino
27-marzo-04
Esercizio 1
Lo scenario che hai ricostruito è coerente con la traccia, lo condivido.
Originally posted by GinoPilotino
sinceramente da qua in poi non ho ben capito come si svolge la cosa.
a) se i bytes inviati da port B arriva all'hub B e vengono smistati da questo sia su B1 che su B2 prima che allo stesso hub arrivino i dati inviati da B2, è la porta dell'host B2 a rilevare la collisione e si ferma lasciando indisturbata la comunicazione tra port B e B1?
b) se invice i bytes inviati da B2 giungono all'hub B prima che giungano quelli da port B dello switch, a rilevare la collisione e quindi a fermarsi è la porta B dello switch?
illuminatemi.
Queste dovrebbero trasformarsi da domande in casi, non è possibile determinare quando la collisione avverrà... ma la domanda 1 chiede "che succede?", si risponde semplicemente "Collisione".
Poi viene la domanda 2, "che deve fare il bridge?", di fatto ci suggerisce che è il bridge che ha scoperto la collisione (magari nn è così, ma giusto per seguire una linea logica). Risposta: Il bridge a quel punto lancia un bel jam signal e blocca la trasmissione del pacchetto MACA. MACB continua ad essere ricevuto sulla PortaB del bridge (per la cronaca: il pacchetto MACB verrà poi anche girato alla LANA assumendo che il bridge non sappia dove si trova LANB1). Sulla PortaA intanto prosegue la ricezione di MACA. Il cut-and-through è andato a farsi friggere perchè è tutto occupato.
Domanda 3: Come ho detto LANA1 continua a trasmettere sulla PortaA del bridge, il bridge però memorizza il resto dei dati in attesa che la PortaB si liberi.
Domanda 4: Di fatto il bloccare la trasmissione verso la LANB è un'interferenza con la trasmissione di MACA ma nn riguarda la trasmissione da parte di LANA1
Originally posted by GinoPilotino
L'ultima domanda dell'esercizio invece dovrebbe essere così: A1 ha inviato il pacchetto verso l'hub A, che lo ha inoltrato ad A2 e a port A nello switch.
ora il pacchetto giunto allo switch viene gestito da quest'ultimo e nella lan A se A2 invia un frame ad A1 prima che B1 riceva il pacchetto di A1 non ci sono comunque collisioni nel dominio lan A.
Domanda 5: nn hai considerato che LANA1 continua a trasmettere quando la PortaB inoltra i primi bit di MACA alla LANB... quindi la collisione c'è, viene riconosciuta da qualcuno (LANA1 o LANA2), questo si blocca e attende che l'altro finisca. Il bridge cmq in questo caso nn inoltra MACA' alla LANB perchè sa che LANA1 è raggiungibile dalla PortaA.
Ragionaci e fammi sapere che ne pensi
Roberto
PS abbiamo perso 2 ore in chat e qua c'ho messo 15 minuti :twisted: |
| GinoPilotino |
ma io ho un dubbio:
a) mettiamo che a1 invia i frame verso lo switch, i pacchetti, intanto b2 comincia la comunicazione, i pacchetti arrivano all'hubB che li dirige verso b1 e port b dello switch.
lo switch comincia a ricevere i primi bytes da port A e cerca subito di inviare i primi bytes su portB, poi s'accorge della collisione e stoppa...fin qui ok.
ma mettiamo che...
b) nell'esercizio si dice che i pacchetti sono stati inviati da a1 verso b1 e che b1 non ha ancora ricevuto i pacchetti. per definizioni i bytes inviati dallo switch quando arrivano all'hub vengono deviati sia su b1 che su b2.
e se i bytes inviati dallo switch fossero già arrivati all'hubB e fossero già in cammino sul link verso b1 e b2?
b2 non ha ricevuto ancora bytes da a1 e prova a comunicare con b1; dato che gli host implementano anch'essi l'algoritmo csma ad accorgersi della collisione non sarebbe mica prima b2 rispetto allo switch? quindi lo switch continuerebbe a trasmettere tutto il pacchetto?
ultima domanda riguardo alle subnet.
un IP 125.124.123.122/24 è diverso da 125.124.123.122/23 oppure sono uguali? nel senso, la subnet la usiamo solo quando un ruoter vuole inoltrare un pacchetto verso una determinata sottorete? |
| futurbaggio |
Originally posted by GinoPilotino
ma io ho un dubbio:
Questo è l'altro caso che ho volutamente ignorato perchè dal testo si capisce che pare che sia + interessante che sia il bridge a notare la collisione.
Originally posted by GinoPilotino
ultima domanda riguardo alle subnet.
un IP 125.124.123.122/24 è diverso da 125.124.123.122/23 oppure sono uguali? nel senso, la subnet la usiamo solo quando un ruoter vuole inoltrare un pacchetto verso una determinata sottorete?
La notazione IP/numero si usa
- per indicare il CIDR, cioè per indicare il numero di bit identificativo di una sottorete, praticamente 125.124.123.122/23 significa che la sottorete è identificata dai primi 23 bit uguali.
- per indicare il range di indirizzi che compongono una subnet, 10.0.0.0/23 indica che gli ip degli host della sottorete variano tra 10.0.0.1 e 10.0.0.23
Claro?
Roberto |
| futurbaggio |
Originally posted by GinoPilotino
qui sono molto incerto; ogni host è collegato con un canale diretto, quindi full duplex con lo switch.
Non essendoci mai collisioni all'interno della rete poichè vengono utilizzati canali distinti per invio e ricezioni dati da host e switch e viceversa, a parte una possibile coda che alcuni frame possono trovare alle porte dello switch non sfruttano sempre la piena banda?
Credo che la condizione per ottimizzare sia passare dallo store-and-forward al cut-and-through. Così si eliminano tutti i possibili ritardi...
Roberto |
| Mac |
Originally posted by futurbaggio
Poi viene la domanda 2, "che deve fare il bridge?", di fatto ci suggerisce che è il bridge che ha scoperto la collisione (magari nn è così, ma giusto per seguire una linea logica). Risposta: Il bridge a quel punto lancia un bel jam signal e blocca la trasmissione del pacchetto MACA. MACB continua ad essere ricevuto sulla PortaB del bridge (per la cronaca: il pacchetto MACB verrà poi anche girato alla LANA assumendo che il bridge non sappia dove si trova LANB1)
Condivido tutto il ragionamento a parte il jam signal...
Io ho capito (probabilmente sbagliando) che il jam signal viene lanciato da MACB subito dopo aver interrotto la propria trasmissione (dato che "intercetta" la trasmissione di A e si stoppa, ma quei pochi bit che trasmette non bastano per far capire ad A che c'è stata una collisione; quindi manda il jam da 48bit per essere chiaro :) ). Quindi è vero che si stoppa la trasmissione di MACA, ma anche MACB viene interrotto dato che ci troviamo in uno slot di collisione (e quindi il mescolamento dei dati non garantisce l'integrità per entrambi i pacchetti). Da qui inizia la fase di backoff in cui tutti e due i pacchetti "attendono" per reiniziare la propria trasmissione in uno slot libero...
(Prova a vederti l'esempio che viene fatto proprio nel paragrafo 5.5.2, pg 461) |
| GinoPilotino |
oh, così forse ci siamo! entrambi si stoppano! non solo uno!
attendo per un tempo random, se è uguale (sfiga) se reincocciano e si ristoppano. se è diverso e basta per trasmettere senza collisioni siamo a posto.
corretto? |
| Flavia |
ma non è solo uno che si stoppa e aspetta un tempo random?Sarebbe uno spreco che si fermassero tutte e due!
:? |
| GinoPilotino |
| in effetti è vero. se si fermassero tutti e ogni volta ci fosse una collisione non trasmetterebbe mai nessuno |
| Flavia |
se è trasportato un messaggio A e il messaggio B inizia la trasmissione, allora A si ferma ma B continua a viaggiare. A poi aspetta un tempo random prima di ripartire e il mittente viene anche informato con un jam signal che questo A deve essere ritrasmesso!
:-D
No? |
| Mac |
Originally posted by Flavia
se è trasportato un messaggio A e il messaggio B inizia la trasmissione, allora A si ferma ma B continua a viaggiare. A poi aspetta un tempo random prima di ripartire e il mittente viene anche informato con un jam signal che questo A deve essere ritrasmesso!
:-D
No?
Il libro sembra indichi proprio l'esempio a cui ci riferiamo! (vedi mio precedente post)
E proprio il libro dice che B che trova il canale occupato (mentre A sta trasmettendo) aspetta il suo turno in uno slot (temporale o di banda) e trasmette solo dopo che A finisce di spedire pacchetti. Poi parte B a trasmettere.
Ma l'esercizio dice che, mentre un frame MACA sta per arivare a LANB2 ("[..]prima che questi (bit) raggiungano la stazione LANB2"), LANB2 INIZIA a trasmettere a LANB1 (proprio perchè nn ha ancora ricevuto MACA)
quindi appena LANB2 riceve MACAinterrompe la trasmissione di MACB, LANB2 lancia il jam al bridge che stoppa tutto. Quello slot è corrotto ed il frame è perso. Random per chi parte per primo!
Claro? ;)
rivedere l'esempio sul libro :)
EDIT: il bridge=switch accetta qualsiasi connessione (la prima che arriva), sono LANB1 e 2 che randomizzano per trasmettere, il primo vince. |
| GinoPilotino |
halt! ma se i frame inviati da i due sono persi, come dici tu, devono ricominciare a trasmettere A1 e B2 sperando che il tempo di sosta di ognuno consenta loro di non riincocciarsi?
effettivamente sul libro c'è scritto che se due pacchetti si scontrano su un link vengono persi entrambi...ha una sua logica.
quindi il junk message giunge broadcast tutti gli host a1,a2, b1 e b2? |
| Mac |
Originally posted by GinoPilotino
quindi il junk message giunge broadcast tutti gli host a1,a2, b1 e b2?
sisi, tutti i pacchetti arrivati all'hub vanno a tutti quelli della rete quindi il jam arriva a tutta LANB e al bridge (nn so se il bridge replichi il jam anche a LANA) |
| GinoPilotino |
suppongo di si visto che il jam per definizione è broadcast.
però qui sono sempre tutte supposizioni. :(
basta, vado a letto che tra 6 ore devo alzarmi. |
| No?Ya! |
Penso che il segnale di jam sia inviato da una delle due entità che counicano, ma comunque il segnale interrompa la trasmissione di entrambi. Se non si bloccassero enrambi non avrebbe senso mandare un jam signal da A a B. Il senso è che appena collidono i due frame, per forza di cosa il segnale si corrompe...
... beh almeno credo :roll: |
| francyghisla |
| concordo con No?Ya!, appena avviene una collisione tra due frame vengono corrotti entrambi... come per il frontale tra due treni su uno stesso binario (tornando agli esempi di gfp!) |
| futurbaggio |
Originally posted by Mac
Condivido tutto il ragionamento a parte il jam signal...
Grazie per la segnalazione, mi era sfuggito quel pezzo...
Cmq la situazione nn cambia di molto, si aspetta che uno dei due trasmetta senza collisioni poi si procede come avevo detto io, no?
Roberto |
| futurbaggio |
Esercizio 1 del 18 - 06- 04
Una rete locale IEEE 803.3 (Ethernet) è costituita di due router (R1 e R2) biporta, di due bridge (B1 e B2) biporta e di due stazioni (S1 e S2), collegati tra di loro secondo il seguente schema:
la stazione S1 è collegata a una delle porte di B1, l’altra porta del quale è collegata a una delle porte di R1
la stazione S2 è collegata a una delle porte di B2, l’altra porta del quale è collegata a una delle porte di R2
la porta di R1 non collegata a B1 è collegata a sua volta alla porta di R2 non collegata a B2
In altre parole, i sei (6) apparati di cui sopra formano una catena (lineare) S1-B1-R1-R2-B2-S2.
La stazione S1, di indirizzo IP1, intende inviare un pacchetto IP alla stazione S2, di indirizzo IP2. Si descriva la struttura dei frame MAC trasmessi lungo la catena che conduce da S1 a S2 (i cui indirizzi MAC sono, rispettivamente, MAC1 e MAC2) transitando attraverso i due bridge e i due router, mettendo in luce quali indirizzi MAC e quali indirizzi IP vengano utilizzati nei vari passaggi.
Sfruttando il protocollo ARP S1 trasmette un frame MAC per conoscere il MAC Address del router R1, questo ovviamente risponde; quindi S1 invia un frame MAC con MAC Address uguale a quello del router e IP uguale a quello della macchina che vogliamo conttatare (S2 di indirizzo IP2). R1 confronta la sua routing table e capisce che deve inoltrare il pacchetto a R2, prima però, tramite ARP, invia un frame MAC per ottenere il MAC Address di R2. Quindi genera un nuovo pacchetto con MAC Address di destinazione uguale a quello di R2 e IP destinazione uguale sempre a IP2. R2 scorre la sua routing table e capisce su che interfaccia inoltrare il pacchetto, ovviamente però prima ricorre ad ARP per conoscere il MAC Address di S2, una volta ricevuta la risposta il pacchetto può essere inoltrato con MAC Address uguale a MAC2 e IP uguale a IP2. I bridge B1 e B2 non fanno altro che inoltrare i frame che ricevono, non dovrebbero costituire un ostacolo o interferire in alcun modo con le comunicazioni.
Roberto |
| Mac |
Originally posted by futurbaggio
Cmq la situazione nn cambia di molto, si aspetta che uno dei due trasmetta senza collisioni poi si procede come avevo detto io, no?
Si si ;) ..però bisogna riadattare il tutto:
a)Collisione ;)
b)il bridge potrà continuare a ricevere MACA su PORTA bufferizzando; intanto scarta il pacchetto su PORTB che dovrà essere rispedito. Il cut-throught funziona in quanto MACA viene subito rispedito senza bisogno di inoltrare il jam anche a LANA
c)le azioni potrebbero interferire (nel caso in cui il bridge decida di stoppare anche LANA1) ma se tutto va come detto sopra questo provvedimento non dovrebbe essere preso
d)No
e)beh in questo caso LANA1 sicuramente non riesce più a trasmettere con integrità. Pertanto il bridge trasmette il frame incorretto a LANB1 (che lo scarta) e rimette tutta la LANA in attesa random. Le azioni interferiscono di sicuro con MACA e dovranno necessariamente interferire con la trasmissione (stop a LANA1e2)
Che ne pensi? |
| futurbaggio |
Originally posted by Mac
Il cut-throught funziona in quanto MACA viene subito rispedito senza bisogno di inoltrare il jam anche a LANA
Ma MACA nn era per LANB1... PortaB difatti è in attesa random, quindi si può pensare che nn sia proprio cut-and-through... almeno nn da subito!
Roberto |
| Mac |
Originally posted by futurbaggio
Ma MACA nn era per LANB1... PortaB difatti è in attesa random, quindi si può pensare che nn sia proprio cut-and-through... almeno nn da subito!
Roberto
Si, hai ragione, almeno non da subito...
il cut-throught inizia sicuramente dopo che LANB2 smette di trasmettere (e quindi la porta B si libera). Questo vale se si presuppone che LANB2, ricevendo anch'esso MACA, non inizi a ri-trasmettere finchè sente il canale occupato
...almeno credo :pensa: |
| futurbaggio |
Originally posted by No?Ya!
[B]Penso che il segnale di jam sia inviato da una delle due entità che counicano, ma comunque il segnale interrompa la trasmissione di entrambi. Se non si bloccassero enrambi non avrebbe senso mandare un jam signal da A a B. Il senso è che appena collidono i due frame, per forza di cosa il segnale si corrompe.../B]
No?Ya quoto te ma mi rivolgo anche Gino e francy...
Io vedo qui un interessante caso in cui ha senso parlare di dominio di collisione... in questo caso sono due (LANA e LANB), il jam signal quindi resta all'interno del dominio di collisione LANB quindi chi smette di trasmettere sono LANB2 e la PortaB (il bridge implementa il CSMA/CD, quindi sa rilevare collisioni e jam signal).
Quello che la PortaB aveva già inviato dovrà essere ritrasmesso, ma sempre dal bridge... penso infatti che, pur facendo cut-and-through, il pacchetto sia cmq memorizzato fintanto che tutta la trasmissione nn è terminata. Questo cmq nn blocca la trasmissione da parte di LANA1.
Roberto |
| francyghisla |
io non sarei così sicura del fatto che un pacchetto rimanga memorizzato nel buffer finchè non è completamente inviato... anzi penso che appena un bit viene prelevato dal buffer e inviato direttamente in modo da avere subito memoria nel buffer libera, se no non avrebbe neanche senso la gestione dei pacchetti corrotti o persi a livello transport, sbaglio?
-> altro quesito di settembre 2004
Una rete locale IEEE 803.3 (Ethernet) è costituita di un bridge B triporta, di tre router (R1, R2 e R3) quadriporta, e di tre stazioni (S1, S2 e S3) monoporta. Le quattro porte del router Ri (per i=1,2,3) sono utilizzate come segue:
• una porta collega Ri alla stazione Si
• una seconda porta collega Ri al bridge B
• ciascuna delle due porte rimanenti collega Ri a uno degli altri router
Quali effetti può produrre nella rete sopra descritta, dal punto di vista della abilitazione/disabilitazione dei vari collegamenti, l’esecuzione dell’algoritmo di spanning tree da parte del bridge B? Non si dimentichi di giustificare la risposta
per me non c'è nessun effetto perchè lo spanning tree è un protocollo di livello network e il bridge, essendo un dispositivo di livello data link, non può implementarlo.
-> è una mia idea malsana che possa esistere una domanda simile o ho preso un granchio? |
| futurbaggio |
Originally posted by francyghisla
io non
sarei così sicura del fatto che un pacchetto rimanga memorizzato nel buffer finchè non è completamente inviato... anzi penso che appena un bit viene prelevato dal buffer e inviato direttamente in modo da avere subito memoria nel buffer libera,
Ai fini dell'esercizio nn so se è così importante saperlo (tu pensi all'ottimizzazione della memoria, io penso all'ottimizzazione dei tempi di *ri*trasmissione), quello che si deve sapere è che il jam signal nn va oltre il bridge in quanto nn è un frame Mac ma un segnale elettrico... i bridge nn gestiscono segnali elettrici (lo fanno gli hub) quindi la collision detection è limitata alla LANB... LANA1 continua a trasmettere, magari poi dovrà rifarlo perchè il frame è corrotto ma questo avviene in un momento successivo a quello di nostro interesse...
Originally posted by francyghisla
se no non avrebbe neanche senso la gestione dei pacchetti corrotti o persi a livello transport,
Non tutti i protocolli esistenti e futuri a qualsiasi livello superiore al data-link devono necessariamente implementare un sistema di controllo degli errori...
Originally posted by francyghisla
sbaglio?
Siamo tutti sullo stesso piano, nn mi sento di avere un giudizio superiore a quello degli altri per questo preferisco che i miei pareri restino tali e nn divengano automaticamente verità solo perchè associati al mio nickname.
E' un appunto, nn una critica o una polemica...
Originally posted by francyghisla
per me non c'è nessun effetto perchè lo spanning tree è un protocollo di livello network e il bridge, essendo un dispositivo di livello data link, non può implementarlo.
-> è una mia idea malsana che possa esistere una domanda simile o ho preso un granchio?
Scorrendo le slide dell'anno scorso ho visto che lo spanning tree è considerato un algoritmo eseguito proprio dai bridge per evitare strutture cicliche e ridondanza di trasmissioni (evidentemente qualcosa di diverso da quanto riportato sul libro).
Il bridge centrale a questo punto non può fare altro che bloccare tutti i suoi collegamenti verso i router, delegando l'inoltro dei pacchetti ai singoli router.
Roberto |
| francyghisla |
aaahh e perchè il libro non dice che può essere anche un protocollo implementabile dai bridge!?!?! in effetti parla di nodi e non di router, ma fino a due pagine prima parlava solo ed esclusivamente di router... ahiai, una piccola pecca!
mi semrbava strano che potesse essere una domanda così a trabocchetto! |
| GinoPilotino |
Originally posted by futurbaggio
i bridge nn gestiscono segnali elettrici (lo fanno gli hub)
io dal libro ho capito l'inverso, ossia i bridge implementano protocolli per la rilevazioni delle collisioni, gli hub no :shock: |
| futurbaggio |
Originally posted by GinoPilotino
io dal libro ho capito l'inverso, ossia i bridge implementano protocolli per la rilevazioni delle collisioni, gli hub no :shock:
Non devi aver capito cosa intendessi... certamente non ho detto quello che tu hai capito :twisted:
Il jam signal (come dice il nome) è un segnale elettrico che, quindi, non ha alcun significato a livello data-link. Un bridge, dispositivo di livello data-link, non ha la capacità di inoltrarlo in quanto nn ha significato a livello 2.
Accade la stessa cosa quando un router riceve un frame Mac nn indirizzato al suo Mac Address.
Roberto |
| GinoPilotino |
| capito...oh almeno, questa è la nostra versione...la accendiamo? :D |
| Alis |
Io ho un dubbio, nell'esame del 6/12/04 primo esercizio, la domanda chiede: quali effetti può produrre nella rte sopra descritta dal punto di vista della abilitazione/disibilatazione dei vari collegamenti, l'esecuzione dell'algoritmo di spanning tree da parte dei tre bridge?
potrebbe essere corretto che l'algoritmo disibilita le porte che vanno dai bridge 1,2,3 al ruoter? |
|
|
|
|
