Příjemci jsou uspořádáni do logického kruhu, jeden z příjemců má token. Odesílatel posílá zprávu všem normálním multicastem a čeká na ACK od příjemce s token. Příjemce s token posílá ACK všem normálním multicastem, ostatní příjemci posílají normálním multicastem NAK s označením přeferovaného příjemce s token. Zprávy obsahují identifikaci odesílatele a lokální pořadové číslo, ACK obsahuje globální pořadové číslo. Příjemce s token jej předá svému následníkovi po odeslání ACK, následník může přijmout token pouze pokud přijal všechny zprávy s nižším globálním pořadovým číslem.
Popsaný mechanismus dovoluje source ordering pomocí lokálního pořadového čísla a total ordering pomocí globálního pořadového čísla. V kruhu délky N také omezuje potřebnou vyrovnávací paměť na N zpráv, protože všechny starší zprávy byly již nutně doručeny.
Vlastnosti se dají nastavovat u každé zprávy zvlášť. Toto nastavení ovlivňuje, kdy jsou přijaté zprávy doručeny na straně příjemce:
Unreliable. Zpráva je doručena v okamžiku přijetí.
Reliable Unordered. Zpráva je doručena v okamžiku přijetí. Pokud příjemce detekuje výpadek lokálního pořadového čísla, pomocí NAK požádá o zprávu příjemce s token.
Reliable Source Ordered. Zpráva je doručena v okamžiku přijetí všech zpráv s nižším lokálním pořadovým číslem od stejného odesílatele.
Reliable Totally Ordered. Zpráva je doručena v okamžiku přijetí všech zpráv s nižším globálním pořadovým číslem.
K Resilient. Zpráva je doručena ve chvíli, kdy byly přijaty všechny zprávy s nižším globálním pořadovým číslem a token byl předán K-krát. Zaručuje, že nejméně K+1 uzlů přijalo paket, a tedy výpadek nejvýše K uzlů nezpůsobí ztrátu dat.
Agreed Delivery. Jako K resilient s K = (MaxN+1)/2, MaxN je odhad nejvyššího počtu uzlů ve skupině, skupina s méně než (MaxN+1)/2 uzly nesmí pokračovat v provozu. Zaručuje atomický provoz i při rozpadu skupiny.
Safe Delivery. Jako K resilient s K = N, N je počet uzlů ve skupině. Zaručuje atomický provoz.
Je dobře poznamenat, že protokol nedovoluje uzlu vrátit se do multicast skupiny pod stejnou identitou. Také je důležité, že všechny volby vlastností doručení ovlivňují pouze latency, nikoliv thruput.
Prikladem je TRP (Token Ring Protocol), RMP (Reliable Multicast Protocol). RMP rozsiruje TRP pro velke site, kde se pouziva hierarchie logickych kruhu (tedy, udajne, nasel jsem to v jednom prehledovem clanku, ale v samotnem popisu RMP ne). RMP mapuje multicast groups na IP multicast addresses pomoci hashovani, pokud dve skupiny dostanou stejnou IP multicast address, oddeluji svoje pakety pomoci multicast group ID.
Na detailnejsi urovni je RMP slozeny z peti algoritmu. Prvni, delivery algoritmus, je primocary podle toho, co bylo dosud popsano.
Druhy algoritmus je membership change, zajemce o pripojeni multicastuje pozadavek dokud nedostane odpoved, tu posila token site, ktere zaroven preda token novemu zajemci o pripojeni. Odpojeni vyzaduje, aby uzel zustal clenem skupiny dokud schovava pakety pro resend. Protokol zarucuje virtual synchrony, ktera rika, ze pokud nekdo joins or leaves a multicast group, vsichni se shodnou na tom, ktere zpravy byly pred a ktere po group membership change.
Treti algoritmus je fault recovery, vyvolany kdykoliv se zjisti, ze nejaky uzel multicast group selhal. Iniciator fault recovery nejprve zkousi kontaktovat vsechny uzly multicast group a vyzvedet od nich, ktere pakety naposledy prijali. Pokud zjisti, ze nekomu chybi paket, ktery nekdo jiny ma, oznami to, tohle opakuje tak dlouho, nez se vytvori nova skupina uzlu, ktere prijaly stejne pakety. Tehle skupine pak pomoci dvoufazoveho commitu oznami jeji slozeni.
Ctvrty algoritmus dovoluje uzlum mimo multicast group posilat zpravu do multicast group a vybranemu uzlu odpovedet, vynechavam :-) ...
Paty algoritmus ma na starost flow and congestion control. Je podobny Van Jacobsonove algoritmu z TCP, tedy sliding window, ktere se dynamicky meni podle toho, zda se dari nebo nedari odesilat.