Abstract
修復伺服器是一個擁有特輸功能的路由器或是和路由器設置在一起的主機，用來幫助群播協定修復錯誤或遺失的封包。到目前為止所有被提出的可靠群播協定都沒有提出選擇修復伺服器的明確方法，當使用這些可靠群播協定時，只能憑設定者以其主觀的看法選擇修復伺服器。然而每個人的選法往往各不相同，結果也可能相差甚遠，最差的情形可能和隨機選沒什麼兩樣，所以如果缺乏選擇的憑據，很可能使得一個設計完美的可靠群播協定無法發揮預期的功能，最後結果大打折扣。為了使修復伺服器的使用更有效率，在這篇論文中提出三個修復伺服器的設置方法，對於一個已知的網路架構，選出所要個數的點來當做修復伺服器放置處，並和隨機擺放的方式做比較。經由程式模擬結果證明這三個方法比起隨機擺放的方式可獲得更好的表現，其中k-maximum path count方法在各方面都有最佳的結果。所謂的修復伺服器是指在群播協定中負責快取資料並做修復的伺服器，可能是一個擁用額外功能的路由器或是群播group中的end 主機(e.g. logging 伺服器、designated 接收端)，一個群播group中可能同時有多個修復伺服器存，共同合作做到分散修復overhead及區域修復的工作，而修復伺服器也可以建立成階層結構，上層的修復伺服器除了負責自己底下的接收端送來的修復要求，也負責處理下層修復伺服器送來的。有些修復伺服器更可以做ACK/NACK的fusion，如果修復伺服器沒有NACK要求的封包，則向傳送端或其他修復伺服器送出NACK，並記錄下已送出的NACK，在修復封包到達之前，如果有其他下游的修復伺服器或接收端送來NACK要求同一個封包則不再送出這個NACK，可大大減少NACK封包在網路上傳送的數量。修復伺服器也可以決定要對其負責的區堿做unicast 重送或者是做一次群播重送以滿足所有發生封包遺失的接收端，另外的變形是只對有送NACK來的link做partial 群播，或是收到多少個NACK之前以unicast做重送，超過多少NACK後改用群播一次送出。這些都是修復伺服器可以幫助群播的功能，視不同協定的設計而有不同的變化。