可靠IP組播通信中間件研究與實現

李磊 陳靜

鄭州大學信息工程學院 河南 450001

0 引言

目前，多數商品期貨交易所的行情發布主要使用TCP/IP進行可靠數據的傳輸。TCP通信需要建立端對端的連接，在行情發布中，傳輸的數據大部分是重復的，這些重復傳輸的數據連接占用大量網絡帶寬，隨著交易規模擴大，就會出現網絡容量上的瓶頸。

IP組播提供一對多和多對多的數據通信，可以減少網絡中重復數據傳輸個數。基于UDP協議的IP組播進行數據傳輸是不可靠的，針對這個問題，研究并設計了基于IP組播的可靠組播通信中間件。

1 可靠組播技術概述

可靠組播技術是基于IP組播的基礎之上，加上報文的差錯檢測和差錯恢復機制，保證了數據傳輸的可靠。

1.1 IP組播的特點

IP組播是基于UDP協議，使用D類地址，把數據分組發給網絡中的一組主機。它具有以下幾個特點：

(1) 盡力傳遞，不保證接收。

(2) 無安全機制，任何主機都可以加入組播組中。

(3) 不提供擁塞控制和流量控制。

(4) 一次發送，多次接收。

雖然IP組播存在著一定的問題，但 “一次發送，多次接收”的網絡數據傳輸效率，加上由此引伸出的網絡的可伸縮性的優點，是單播中無法企及的。如果對IP組播技術進行可靠性的改進，組播技術在實際應用中有著廣泛的空間。

1.2 IP可靠組播關鍵技術

雖然IP組播存在著一些弱點，但在其基礎上加上差錯恢復技術和擁塞控制機制及其他安全手段，可以保證數據在傳輸過程中的可靠性和穩定性，以在實際應用中使用。可靠組播可以用下式表示：

可靠組播=IP組播+[差錯檢測恢復]+[擁塞控制]

2 可靠組播通信中間件協議設計

2.1 可靠組播通信中間件的特性

本文可靠組播通信中間件是面向中小型交易的，它在實際應用做作為行情發布的通信支持。因此，它是一個針對性比較強的組播通信中間件。具體表現為以下特征：

(1) 平面組織結構：平面組織結構和層次性組織結構相比，通信的規模比較小，但是報文的傳送速度比較快，報文可以直接到達。它是基于實際中要求通信規模不大，但是實時性能要求很高的特點進行設計的。

(2) 報文拆分合并功能：在數據傳輸的過程中，由于來自應用程序的單個數據可能超過UDP報文的最大荷載長度，因此為了保證數據能夠完整的傳輸，需要對其進行拆分，與此同時，在接收端提供對拆分過的數據進行合并的功能。

(3) 可選的小報文的合并功能：為了提高組播的傳輸效率，提高網絡鏈路的利用率，提供了對小報文的可選合并功能，當網絡不好而接收方和發送方有比較充裕的時間，則可以開啟此功能，提高傳輸效率。此功能屬于可選項，在實際應用中可以選擇是否開啟。

(4) 單可靠組播通道，多地址傳送：為了滿足正常數據報文和重傳數據報文的合理傳輸，并能夠支持發送端和接收端的雙向通信功能，將其多播傳送地址分開，有專門負責正常數據傳送和重傳報文的發送地址。

(5) 單播組播可選恢復機制：對于錯誤報文的發現和恢復的情況，都分別提供了單播和組播的功能實現，上層應用可以根據對于錯誤報文的需要進行合理選擇。在默認使用組播的情況下，協議采用組播完成錯誤報文的恢復機制。

2.2 協議報文設計

協議數據報文的設計分為兩類：可靠組播中的UDP報文和可靠組播數據報文。

(1) UDP報文：它由UDP報文頭和可靠組播數據報文組成。可靠組播數據報文填充UDP報文，根據填充規則，可以是一個可靠組播數據報文也可以是多個可靠組播數據包。如圖1所示。

圖1 包含多個組播報文的UDP包結構

(2) 可靠組播數據報文：它是由可靠組播報文頭和可靠組播數據組成。可靠組播報文頭是可靠組播設計的重點，它需要滿足不同要求的數據傳輸，并要求對報文進行快速處理，因此報文頭部分采取定長，并提供報文類型、服務質量、優先級、是否數據進行拆分等信息。可靠組播報文頭部結構如圖2所示。

(3) 主要報文類型：在可靠組播中，提供了數據報文和控制報文。主要的數據報文為正常數據報文，重同步請求報文，重同步數據報文，心跳數據報文，重開始發送報文等，并對同等條件下的報文提供不同的優先級。

2.3 關鍵技術

可靠組播通信中間件的設計中，為了保證數據的可靠傳輸，也必須用合理的差錯恢復和擁塞控制的方法。

(1) 差錯恢復和差錯檢測的處理方法

采用基于NACK的方式來進行差錯檢測和恢復。數據接收端利用協議中設計的序列號字段檢測，當收到的序列號不是期待的，可以認為數據丟失。由于在傳輸過程中，有可能并不是一個接收端丟失數據，因此接收端等待一定的時間間隔，才向發送端請求數據重傳。

為保證傳送的效率，發送端對發送數據進行緩沖管理，當有數據重傳請求時，可以快速給出響應。

(2) 擁塞控制的處理方法

在傳輸過程中，采用基于速率的擁塞控制方法，采用的擁塞控制方式為LHR。當有NACK到達發收端時，降低發送速率，當沒有收到NACK時，增加發送速率，從而保證了能夠及時處理大量的數據。

為保證數據的平滑發送，提供最大和最小的發送速率，在最大最小發送速率中提供若干個速度等級用于調節發送速率平衡，從而很好的控制傳輸速率，不讓網絡發生劇烈“抖動”。

3 可靠組播通信中間件的實現

3.1 實現框架

本文可靠組播協議最終的實現是以邏輯流為基本通信單位的通信中間件。在一個邏輯流中，數據發送端和數據接收端按照可靠組播協議進行通信，為了保證通信的實時性和數據處理的快速行，對數據發送、恢復、合并、拆分等過程采用多線程的機制進行協調處理。

對于一個邏輯流，按照任務的不同，分為數據接收端和數據發送端。其中數據發送端在一個邏輯流中有且只有一個，數據接收端可以是多個。數據發送端作為數據的輸出端，接收端即為一個數據的出口，它把數據給應用程序使用。一個完整的邏輯流包括發送端和接收端，以及協調發送和接收端的一些公共模塊，根據可靠組播協議的設計，實現一個邏輯流的結構如圖3所示。

圖3 邏輯流的層次結構

在一個邏輯流中，最重要的部分為邏輯流的發送端和接收端，下面分別對發送端和接收端的實現進行描述。

3.2 數據發送端

發送端借助于計時器，對上層應用的數據進行拆分/合并，并對發送的數據進行緩存，同時監聽重傳請求，對請求進行響應。它包括以下數據結構和線程：

(1) 主要數據結構

① 上層應用數據隊列：當應用程序調用發送數據的函數接口時，即把應用程序的數據放到應用數據隊列中。該隊列使用一個鏈表結構來管理這些大小不一的數據。

② 數據發送隊列：經過發送端的數據處理線程處理以后，把數據進行拆分或者合并，把數據整理成可以直接發送的數據包，放入到發送隊列中。發送隊列可以被發送線程直接發送。

③ 已發送數據的緩存隊列：對于已發送的數據，按照設置進行存儲，用于數據重同步時使用。這里需要注意的是，并不是對所有的數據都進行存儲，而是根據緩沖區大小參數設置，當緩沖區超過此參數時，就把最早進入該隊列的數據進行刪除，添加新的數據節點。

④ 重傳請求隊列：當重傳監聽線程監聽到重傳請求時，把重傳請求放入重傳請求隊列。

(2) 主要線程

① 發送數據處理線程：對上層應用程序進行合并、拆分處理，并且添加相應的可靠組播頭，組裝成待發送數據，填充到可靠組播的數據發送隊列里。

② 發送線程：對數據發送隊列進行發送，同時把已發送的數據緩存到已發送數據的緩存隊列中。

③ 監聽重同步線程：當監聽線程監聽到重同步請求時，為了繼續監聽數據，此時需要把監聽的數據存儲到重同步請求隊列。

④ 重同步處理線程：對重同步請求隊列中的數據進行處理，它從已發送緩存中查找數據，根據查找結果，進行重同步的恢復或者其他處理。

數據發送端主要處理兩個主要工作：數據發送和數據恢復與重傳。它倆緊密聯系，并且提供數據的流量控制。流量控制部分主要放在監聽重同步線程中實現，它的實現方法如下：數據的發送提供不同的速率，監聽重同步線程發現有數據丟失情況，則降低發送速率，沒有重傳請求時，增大發送速率，從而達到數據的平穩傳輸。

3.3 數據接收端

數據接收端負責接收并分析數據，提供差錯檢測功能，同時對數據合并或者拆分，提交到上層應用程序。它主要包括以下數據結構和線程：

(1) 主要數據結構

① 接收數據隊列：用于緩存接收到的數據包。它由數據接收線程接收，數據處理線程進行處理。

② 應用數據隊列：接收端數據處理線程對接收到的數據包進行處理，并對處理過的數據進行緩存，這個緩存隊列就是應用數據隊列，它是提交給應用程序的數據隊列。

③ 重同步請求隊列：當檢查到序列號丟失時，則發送數據差錯的恢復請求，即數據的重同步請求，該請求的報文被放入到重同步請求隊列，由重同步請求線程進行處理。

(2) 主要線程

① 數據接收線程：負責接收數據，并對不同類型的報文做出不同的處理。對數據報文，放入到接收數據隊列。并負責檢測報文是否丟失。

② 數據處理線程：對接收的數據隊列中的數據進行分析，并根據需要對數據進行合并或者拆分操作，對處理過的數據放入到應用數據隊列。

③ 重同步請求線程：對丟失的報文進行重同步請求，它對重同步請求隊列掃描，當有重同步請求時，發送重同步請求。

在一次接收過程中，接收部分的各個模塊之間進行的協調關系，如圖4所示。

圖4 接收端接收數據的處理過程

4 性能測試結果

對網絡協議的測試，目前主要的測試方法包括實際測量，網絡模擬和數學分析等，每個測試的側重點都不盡相同。針對可靠組播通信中間件在實際中使用的情況，主要采用實際測量的方法測試。

4.1 測試方法及環境

4.1.1 測試方法

這里僅對組播測試進行吞吐量的測試，在這個過程中，采用了實際的數據與理論上的吞吐量進行對比。

理論上的吞吐量用總的數據除以數據發送的時間，即得到理論上的吞吐量。

實際的吞吐量采用實際中的參數進行測試，假設每個發送周期都能將發送窗口大小數量的報文發送出去，并且接收端都正確收到，在沒有數據重傳的情況下，利用發送時延計算出每秒鐘發送次數，然后同每次發送的數據量作乘法運算，得出系統的吞吐量，可以通過對其進行設置以調節發送端吞吐量。計算公式為：

公式中各參數的意義為：

Throughput(bps)—— 代表發送端的吞吐量；

PacketSize——代表每個數據包最大數據載荷，內部參數；

Windowsize—— 代表發送窗口大小，即每次發送數據包個數，內部參數；

Timedelay——代表發送時延，以毫秒作為計時單位，內部參數。

上述計算方法是理想狀態下對吞吐量的計算，并未考慮報文丟失，但在實際情況中，系統中會出現不定量的丟包情況。因此，上述方法不能精確反映系統的性能，隨著丟包率的增大，實際的吞吐量將會與計算結果相差越來越大，理想狀態下的吞吐量計算值只能作為參考值，反映吞吐量的上界。

4.1.2 測試環境

實驗在沒有他人使用的網絡的情況下進行，網絡環境為帶寬為100Mbps的局域網。發送主機和4臺接收主機均采用使用的是Redhat Linux操作系統，機器配置均為512M內存，2.8GHz奔騰CPU。

4.2 測試結果及分析

在多種配置下組播傳輸一個2M字節大小的數據塊，其性能，參數，實驗吞吐量，理論吞吐量如表1所示。

表1 實驗數據對比表

實驗結果表明，在該組數據中，觀察到的實驗數據與預期數據比較吻合，一般情況下對協議參數設置在合理范圍內均能達到較好的運行效果。

5 結束語

本文在分析IP組播的基礎上，研究了可靠組播的特點，并結合實際，完成可靠組播通信組件的設計。目前可靠組播通信組件已在行情發布中投入使用，運行穩定。下一步將進行可靠組播通用性的研究，使其能夠應用于多種應用場景。

[1] RFC2357： IETF Criteria for Evaluating Reliable Multicast Transport and Application Protocols. 1998.

[2] Juan-Mariano de Goyeneche. Multicast over TCP/IP HowTo[M].v1.0. March 1998.

[3] J.Widmer, R.Denda, and M.Mauve. A Survey on TCP-Friendly Congestion Control. IEEE NetWork, May/June 2001.

[4] 徐恪,吳建平,徐明偉.高等計算機網絡.機械工業出版社.2003.