Dsy Network www | forum | my | didattica | howto | wiki | el goog | stats | blog | dona | rappresentanti
Homepage
 Register   Calendar   Members  Faq   Search  Logout 
.dsy:it. : Powered by vBulletin version 2.3.1 .dsy:it. > Didattica > Corsi N - Z > Reti di calcolatori > [Soluzioni] Appelli vecchi
  Last Thread   Next Thread
Author
Thread    Expand all | Contract all    Post New Thread    Post A Reply
Collapse
Alis
.grande:maestro.

User info:
Registered: Jun 2002
Posts: 862 (0.10 al dì)
Location: Corsico
Corso:
Anno:
Time Online: 10 Days, 16:32:12 [...]
Status: Offline

Post actions:

Edit | Report | IP: Logged
[Soluzioni] Appelli vecchi

Appello 2/2/04:

Domanda 2: Una stazione è dotata di una interfaccia Ethernet collegata alla rete FastWeb e di una interfaccia ADSL collegata alla rete Telecom Italia. Gli indirizzi IP di dette interfacce sono FW e TI, rispettivamente. Un programma applicativo esegue la primitiva new Socket(FW,4000,TI,4001). Ricordando che uno dei formati di questa primitiva è:

Socket(remoteAddr,remotePort,localAddr,localPort)

si determini a quali condizioni l’esecuzione della predetta primitiva si completa con successo, e si descriva il percorso end-to-end di un pacchetto IP che trasporti segmenti TCP relativi alla connessione che ne viene instaurata.

Domanda 3: Un certo servizio che chiameremo DCEP (Delayed Character Echo Protocol) può essere descritto informalmente come segue: un client invia un byte B a un server DCEP mediante un datagram UDP; il server riceve B; il server si mette in pausa per 3 secondi; il server invia B al client mediante un secondo datagram UDP; il client riceve B. Ora, si immagini che il servizio DCEP venga erogato da un server S parallelo (multithread in Java, multiprocesso in C), e che dapprima un client C1, e successivamente un client C2, richiedano a S il servizio DCEP servendosi della porta P (la stessa per entrambi). Supponendo che i tempi di trasmissione e di propagazione dei datagram UDP siano trascurabili, e che le richieste di C1 e C2 siano distanziate tra loro di un secondo (1s), dopo quanti secondi dalla ricezione della richiesta di C1 il server S riuscirà a completare l’erogazione del servizio richiesta da C2? Come cambia (se cambia) la risposta, nel caso in cui C1 e C2 dovessero rivolgere le loro richieste sempre a S, ma questa volta servendosi – rispettivamente – di due diverse porte P1 e P2? Si giustifichino tutte le risposte.


Appello 23/2/04:

Doamanda 3: Un certo servizio che chiameremo SDP (Dual-Service Directory Protocol) può essere descritto informalmente come segue: con un unico messaggio UDP, un client invia due byte B1 e B2 a un server SDP; il server riceve detti byte e li interpreta come due codici numerici associati ad altrettanti servizi S1 e S2, appartenenti a un portafoglio di 256 servizi possibili; il server consulta una sua tabella interna, utilizzando come indici di accesso i byte appena ricevuti, e – in corrispondenza di detti indici – preleva dalla tabella due sequenze A1 e A2 di quattro (4) byte ciascuna, le quali rappresentano gli indirizzi IP di due macchine M1 e M2 in grado di erogare rispettivamente i servizi S1 e S2 di cui trattasi; il server invia al client, con due distinti messaggi UDP, dapprima i quattro byte corrispondenti all’indirizzo A1, e successivamente i quattro byte corrispondenti all’indirizzo A2; il client utilizza le due risposte nell’ordine per richiedere rispettivamente i servizi S1 e S2 alle macchine di pertinenza. Un programmatore, mentre sta realizzando una implementazione di SDP, si accorge che accade un fenomeno strano: quando un client invia una richiesta a un server SDP, nella maggior parte dei casi – come ci si aspetta – le risposte A1 e A2 vengono ricevute nell’ordine, mentre nei rimanenti casi le due risposte arrivano inaspettatamente in ordine inverso (A2 prima di A1). In tal modo il client viene erroneamente indotto a richiedere il servizio S1 alla macchina di indirizzo A2, e il servizio S2 alla macchina di indirizzo A1, con tutte le conseguenze del caso. Nell’ipotesi che il software realizzato dal programmatore sia privo di errori (ossia che implementi correttamente le specifiche del protocollo SDP sia sul lato del client che sul lato del server), si formuli una spiegazione plausibile di questo fenomeno, e si suggerisca una modifica del protocollo SDP che consenta di eliminare lo spiacevole inconveniente.

Domanda 4: Si discuta se sia vera o falsa la seguente affermazione: “Nelle reti con protocollo CSMA/CD la probabilità che si verifichi una collisione tra pacchetti è tanto più elevata quanto maggiore è il “diametro temporale” della rete, dove per “diametro temporale” si intende il tempo di propagazione dei segnali tra le due stazioni cronologicamente più lontane (ossia tra le due stazioni per cui è massimo il tempo di propagazione dei segnali dall’una all’altra).”


Qualcuno mi da dei consigli su come si risponde alle domande?

grazieeee :(

11-05-2004 12:59
Click Here to See the Profile for Alis Click here to Send Alis a Private Message Find more posts by Alis Add Alis to your buddy list Printer Friendly version Email this Article to a friend Reply w/Quote
Collapse
Gigi
.arcimaestro.

User info:
Registered: Jun 2002
Posts: 350 (0.04 al dì)
Location: Milano - Gallipoli
Corso: Comunicazione Digitale
Anno:
Time Online: 9 Days, 9:34:49 [...]
Status: Offline

Post actions:

Edit | Report | IP: Logged

Guarda i thread vecchi con argomento [Es] ti potranno servire ...

11-05-2004 16:30
Click Here to See the Profile for Gigi Click Here to See the Blog of Gigi Click here to Send Gigi a Private Message Find more posts by Gigi Add Gigi to your buddy list Printer Friendly version Email this Article to a friend Reply w/Quote
All times are GMT. The time now is 17:06.    Post New Thread    Post A Reply
  Last Thread   Next Thread
Show Printable Version | Email this Page | Subscribe to this Thread | Add to Bookmarks

Forum Jump:
Rate This Thread:

Forum Rules:
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts
HTML code is OFF
vB code is ON
Smilies are ON
[IMG] code is ON
 

Powered by: vBulletin v2.3.1 - Copyright ©2000 - 2002, Jelsoft Enterprises Limited
Mantained by dsy crew (email) | Collabora con noi | Segnalaci un bug | Archive | Regolamento | Licenze | Thanks | Syndacate
Pagina generata in 0.074 seconds (53.76% PHP - 46.24% MySQL) con 26 query.