Esempio del mondo reale: TIBCO Rendezvous.
I dati vengono inviati tramite multicast con un numero di sequenza. Un client che rileva un numero di sequenza mancante invia un messaggio al gruppo multicast "hey, ho perso il pacchetto 12345". Il server ri-multicast fuori quei dati. Il server ha una quantità configurabile di dati da memorizzare nel caso in cui un client lo richieda.
Il problema:
immaginare di avere un unico cliente che scende metà dei suoi pacchetti, e 100 clienti sani. Questo client invia una richiesta di ritrasmissione per ogni altro pacchetto. Il server inizia a causare un carico sufficiente su uno dei client sani in modo che inizi a rilasciare pacchetti e richiedere ritrasmissioni. Il carico aggiuntivo da ciò causa che un altro client sano inizi a richiedere le ritrasmissioni. E così via. Una congestione collassa i risultati.
Tibco fornisce una soluzione alternativa per interrompere un utente che invia troppe richieste di ritrasmissione. Ciò rende più difficile per un singolo abbonato causare un collasso di congestione.
L'altro modo per limitare il rischio di compressione della congestione è limitare la quantità di dati che un server è disposto a ritrasmettere.
Tibco deve anche fornire l'euristica nel client e nel server per multicastare o unicast la richiesta di ritrasmissione e la ritrasmissione stessa. Non lo fanno. (Per il server, è possibile unicast della ritrasmissione se solo un client lo ha richiesto in una determinata finestra temporale, per il client è possibile unicast la richiesta di ritrasmissione se il server ti ha detto - nel pacchetto ritrasmesso - che sei l'unico a richiedere ritrasmissioni e per favore unicast le richieste in futuro)
Fondamentalmente dovrete decidere tra quanto forte volete garantire che i clienti ricevano dati rispetto al rischio di crollo della congestione. Dovrete fare ipotesi su dove un pacchetto è stato rilasciato e se la ritrasmissione viene inviata in modo più efficiente unicast o multicast.Se il server comprende i dati e può decidere di non inviare una ritrasmissione se vi sono comunque dati aggiornati da inviare (il che rende irrilevante la ritrasmissione), ci si trova in una posizione molto migliore rispetto a un framework come Tibco RV.
A volte la comprensione dei dati può portare a presupposti errati. Ad esempio, dati di mercato - potrebbe sembrare a prima vista OK non ritrasmettere una citazione quando c'è una citazione aggiornata. Ma più tardi, potresti scoprire che un iscritto stava mantenendo una cronologia delle quotazioni, non solo cercando di tenere traccia della citazione corrente. Forse potresti avere requisiti diversi a seconda dell'abbonato, e alcuni clienti preferiranno unicast TCP o multicast.
A un certo punto è necessario prendere decisioni arbitrarie sul server di quanti dati da bufferare in caso di ritrasmissioni o client lenti.
Quanti ricevitori? Se si dispone di meno di dieci ricevitori, è possibile prendere in considerazione diverse comunicazioni da nodo a nodo. – mcoolive