2015-07-03 26 views
5

mi sto preparando per il mio esame universitario e uno della questione lo scorso anno è stato "come fare UDP multicast affidabile" (come TCP, la ritrasmissione dei pacchetti persi)modalità di attuazione UDP multicast affidabile

ho pensato a qualcosa di simile questo:

  1. Server multicast invio utilizzando UDP

  2. Ogni cliente invia il riconoscimento di ricevere che i pacchetti (con TCP)

  3. Se il server si rende conto che non tutti ricevono i pacchetti, esso invia nuovamente multicast o unicast al cliente particolare

Il problema sono che ci potrebbe essere un cliente che di solito ha perso pacchetti e server di forza di reinvio.

È buono?

+0

Si considera che il riconoscimento nella fase 2 consiste in realtà la connessione al server? Inoltre, il passaggio 3 è potenzialmente infinito, cosa succede se qualche client si trova su una connessione * veramente * non valida o se dispone di un firewall locale che interrompe automaticamente i pacchetti. –

+0

Penso che non ci sia altra opzione che connettersi al server nel passaggio 2. Sì, questo è il problema con il passaggio 3. C'è qualche soluzione? – Laoni

+0

La soluzione per il numero 3 è quella di continuare a riprovare all'infinito o semplicemente di rinunciare a un messaggio di errore dopo un certo numero di tentativi. E se si desidera utilizzare un riconoscimento TCP nel passaggio 2, non c'è davvero altro modo. –

risposta

0

Per rendere UDP affidabile, è necessario gestire alcune cose (ad esempio, implementarlo da soli).

Gestione connessione: La connessione tra il processo di invio e quello di ricezione può diminuire. Le implementazioni più affidabili solitamente inviano messaggi keep-alive per mantenere la connessione tra le due estremità.

Sequenza: I messaggi devono essere suddivisi in blocchi prima dell'invio.

Conferma: Dopo aver ricevuto ciascun messaggio, è necessario inviare un messaggio ACK al processo di invio. Questi messagi ACK possono anche essere inviati tramite UDP, non deve passare attraverso UDP. Il processo di ricezione potrebbe rendersi conto che ha perso un messaggio. In questo caso, smetterà di recapitare i messaggi dalla coda holdback (coda dei messaggi che contiene i messaggi ricevuti, è come una sala d'attesa per i messaggi) e richiede una ritrasmissione del messaggio mancante.

Controllo di flusso: Accelerare l'invio di dati in base alle capacità del processo di ricezione per fornire i dati.

Di solito, c'è un leader di un gruppo di processi. Ciascuno di questi gruppi ha normalmente un leader e una vista dell'intero gruppo. Questa è chiamata una sincronia virtuale.

0

Ogni client invio ricevuta di ricezione che i pacchetti (con TCP)

invio di un ACK per ciascun pacchetto, e utilizzando il protocollo TCP a farlo, non è scalabile per un gran numero di ricevitori. L'utilizzo di uno schema basato su NACK è più efficiente.

A ogni pacchetto inviato dal server deve essere associato un numero di sequenza. Quando i clienti li ricevono, tengono traccia di quali numeri di sequenza sono stati persi. Se i pacchetti vengono persi, un messaggio NACK può quindi essere rispedito al server tramite UDP. Questo NACK può essere formattato come una lista di numeri di sequenza o una bitmap di numeri di sequenza ricevuti/non ricevuti.

Se il server si rende conto che non tutti ricevono i pacchetti, esso invia nuovamente multicast o unicast al cliente particolare

Quando il server riceve un NACK non dovrebbe inviare nuovamente i pacchetti mancanti, ma attendere per un certo periodo di tempo , tipicamente un multiplo del GRTT (Group Round Trip Time - il tempo di round trip più grande tra il set di ricevitori). Ciò gli dà il tempo di accumulare NACK da altri ricevitori. Quindi il server può multicastare i pacchetti mancanti in modo che i client che li perdono possano riceverli.

Se questo schema viene utilizzato per il trasferimento di file in contrapposizione ai dati di streaming, il server può inviare i dati del file in alternativa. Il file completo viene inviato al primo passaggio, durante il quale vengono accumulati tutti i NACK ricevuti e vengono contrassegnati i pacchetti che devono essere nuovamente inviati. Quindi, nelle passate successive, vengono inviate solo le ritrasmissioni. Questo ha il vantaggio che i clienti con bassi tassi di perdita avranno l'opportunità di finire di ricevere il file mentre i ricevitori ad alta perdita possono continuare a ricevere ritrasmissioni.

Il problema è che potrebbe esserci un client che di solito ha perso pacchetti e costringe il server a inviare nuovamente.

Per i clienti molto elevati di perdita, il server può impostare una soglia per la percentuale massima di pacchetti mancanti. Se un client restituisce NACK oltre tale soglia una o più volte (quante volte dipende dal server), il server può rilasciare quel client e non accettare i suoi NACK o inviare un messaggio a quel client informandolo che era caduto.


Ci sono una serie di protocolli che implementano queste caratteristiche:

RFC rilevanti:

Problemi correlati