電騾客戶端和服務(wù)器使用不可靠的
UDP
服務(wù)來保活和搜索增強(qiáng)。由電騾客戶端產(chǎn)生的
UDP
包的數(shù)量（注意，包不是字節(jié)）達(dá)到電騾客戶端發(fā)送包總數(shù)的
5%
；這依賴于在客戶端的服務(wù)器列表中服務(wù)器的數(shù)量、客戶端下載列表中源的數(shù)量以及用戶執(zhí)行的搜索的數(shù)量。
UDP
包通過定時器來觸發(fā)，
100ms
，如果有一個單獨線程來負(fù)責(zé)發(fā)送
UDP
通訊，結(jié)果最大是每秒
10
個
UDP
包。
1.1
??????????????????????
服務(wù)器?；詈蜖顟B(tài)信息
客戶端定期驗證它的服務(wù)器列表的狀態(tài)。這個驗證使用
UDP
服務(wù)器狀態(tài)請求（見
6.3.3
）和
UDP
服務(wù)器描述請求（見
6.3.7
）報文來完成?，F(xiàn)在介紹的簡單的?；钅Ｊ矫總€小時產(chǎn)生少于幾打個包。在任何情況下，最大高產(chǎn)生率是
0.2
個包每秒（或每
5
秒一個包）。當(dāng)檢查一個服務(wù)器的狀態(tài)是，客戶端首先給服務(wù)器發(fā)送一個狀態(tài)請求，然后是每兩個服務(wù)器描述請求一個狀態(tài)請求的方式發(fā)送；見圖
3.1
：
圖
3.1
：
UDP
的保活循環(huán)
服務(wù)器的狀態(tài)請求包含一個隨機(jī)數(shù)，這個隨機(jī)數(shù)在服務(wù)器的響應(yīng)中返回。如果服務(wù)器中返回的數(shù)不同于前面客戶端返回的，響應(yīng)中的信息會被拋棄。每次從客戶端發(fā)送到服務(wù)器的狀態(tài)請求包，客戶端都會啟動一個嘗試計數(shù)器。如果嘗試次數(shù)達(dá)到設(shè)置的最大值是，就認(rèn)為該服務(wù)器是死的，將它從客戶端的服務(wù)器列表中刪除。服務(wù)器響應(yīng)包括幾個數(shù)據(jù)項：服務(wù)器狀態(tài)響應(yīng)（
6.3.4
節(jié)）包括當(dāng)前的用戶數(shù)和服務(wù)器上的文件，服務(wù)器的軟和硬限制（
1.7
節(jié)）。服務(wù)器描述響應(yīng)（
6.3.8
節(jié)）包括服務(wù)器名稱和一個簡單的描述字符串。圖
3.2
描述了一個客戶端和活動服務(wù)器之間的完整?；钚蛄械南⒘?。
圖
3.2
：
UDP
保活序列
1.2
??????????????????????
文件搜索增強(qiáng)
電騾客戶端可能被配置而用來使用
UDP
來增強(qiáng)文件搜索功能。
UDP
搜索請求格式幾乎與
TCP
搜索請求相同。服務(wù)器僅僅在有搜索結(jié)果的時候響應(yīng)。有兩種
UDP
搜索報文的
OPCODE
，我不能他們之間不同。
UDP
搜索包發(fā)送給客戶端服務(wù)器列表中的服務(wù)器。見
6.3.5
和
6.3.6
節(jié)詳細(xì)介紹。
1.3
??????????????????????
文件源搜索增強(qiáng)
當(dāng)客戶端所擁有的下載隊列中的某個文件的源的數(shù)量小于設(shè)置的極限（
100
）時，客戶端定期向它的服務(wù)器隊列中的服務(wù)器發(fā)送
UDP
包來得到更多源。有個包可能每秒都發(fā)送，它時源搜索客戶端產(chǎn)生的
UDP
通訊中最重要部分。消息格式（
6.3.1
節(jié)介紹）和
TCP
計數(shù)器部分非常相似。注意，同
TCP
源搜索比較，
UDP
源搜索與文件搜索是隔離的并且依賴于客戶端擁有的給定文件的源的數(shù)量。