CMPP/SGIP協議設計與實現(轉貼)

移動夢網和聯通在信都是構建在有中國特色的短信網關部件基礎上的，亞信爲中國移動設計的CMPP協議規範，中國聯通的SGIP規範都是爲這個短信網關提供的互聯網接口標準，可以看出二者都是借鑑GSM SMPP協議的兩種簡化版。

CMPP提供了基於TCP的長連接接口和短連接接口標準，SGIP提供了基於TCP和HTTP/TCP的短連接接口標準。CMPP中的短信網關爲TCP服務器，通過接收SP發起的TCP連接來發送MT/MO/Report/Resp等消息。SGIP中發送MT/MTResp時是短信網關爲TCP服務器，發送MO/MOResp/Report/ReportResp時短信網關作爲TCP客戶端。

從CMPP協議的文字內容來看，目前所有的短信網關的設計和實現都不標準。這是很有中國特色的，中國人不擅長搞統一的技術標準和規範，任何兩個系統之間無論什麼接口私下定義一下，就成了。西方人做研究搞技術，涉及到兩個對象（包括人）打交道的，就定義一大堆標準和規範，約束各方。大家嚴格地遵守規範，如果有異議，就有人提議修改標準。很少私下去違反約定的標準來實現某個系統。在通信領域，好不容易出了個協議標準，居然連設計這個標準的廠家也不遵守。中國的法律成千萬，遵紀守法的意識折騰那麼多年還是上不來。

短連接的標準很簡單，建立連接後，發送包，接收響應，發送接受，幾個來回，關閉連接就成了。長連接標準需要有鏈路檢測的維持機制（其實這個思想來自不可靠的鏈路通信，如在數據報基礎上保障可靠傳輸的sync機制）、超時重傳和差錯重傳機制、保障有序的傳輸機制、重複拋棄（duplication removal）機制、流量控制的滑動窗口(Sliding Window)機制。

CMPP協議文字內容中，每個建立起來的TCP長連接，既可以發送MT的Submit消息，也可以從網關側發送MO的Deliver/StatusReport消息，每個連接的作用都是同等的。而在實現網關時，爲這個問題出了很多個實現方法：亞信網關只允許一個TCP鏈接來發送MO消息，可以有多個連接來發送MT消息，區分MT鏈接和MO鏈接的方法是依據開始發送Connect時的協議版本號，爲0是MT，爲1是MO。巨搞笑！我真服了亞信那幫人！自己搞的標準，自己不遵守，作爲中國的第一大電信集成商，不知道拿什麼到Nasdaq上市的。亞信網關還好，什麼陰私克、東軟的網關，稀奇古怪的東西就更多了。讓人懷疑，這不僅僅是技術素養問題了。

反正這麼爛的玩意，有些運營商也用，唉，運營商的技術人員素質更差。我到現在都沒有弄懂，運營商反覆強調他們網關的接受短消息速度是最大每秒10條？要讓所有的SP那裏限制發送速度。這個數據，不知道他們是怎麼得出的？這種政式的命令，讓我無數次罵那個作出這麼荒謬要求的**的祖宗。你網關處理速度慢，這是一個典型的技術問題，你那邊服務器忙不過來，你協議裏定義的滑動窗口機制是幹嗎用的？就是專門用來解決流量控制目的用的。有誰聽說過，美國國防部弄出TCP協議後，服務器那邊接收不過來，要求客戶端限定死，每秒鐘最多隻能發送多少個數據包沒有？這些運營商的技術素養，離國際化的大型企業差的太遠太遠，還到處臭擺自己500強，真是丟中國人的臉！

最後的結局是各個SP的開發人員，不斷地開發好幾家網關的接口，就跟求爺爺似的，聽着這幾個網關供應商和運營商那幫弱智的訓斥。

設計CMPP協議模塊，需要考慮如下幾個需求：
（1）可以人爲配置的多個TCP連接，來發送和接受消息（移動最多可允許一個SP建立15個連接）。系統初啓時，自動地啓動指定個數的連接。運行過程中，任意一個連接崩潰時，自動恢復。
（2）類似心跳消息的長連接維持機制，爲每個連接，在最後一個消息的處理結束前，重新啓動一個60秒的定時器。如果期間有消息來往，停止定時器，處理完消息後，繼續啓動定時器。如果60秒超時，重新啓動定時器，連續三次超時，關閉這個鏈接，重新啓動建立過程。
（3）超時重發和差錯重傳。超時重發的原理是發送每個MT消息後，啓動一個60秒的定時器，等待網關返回應答。如果超時，繼續發送，連續3次都超時都沒有應答，關閉連接，啓動鏈路恢復過程。並將這條消息保存到回收隊列中，千萬別拋棄。差錯重傳是接受到錯誤的應答，並且這個錯誤是由對等通信雙方的協議層產生的，那麼重新發送這條消息。
（4）滑動窗口機制。可以實現流量控制和有效的負載均衡。滑動窗口大小爲16條消息。採用異步方式，一次發送16條消息，並等待應答，每成功一個應答，窗口縮小，然後再從緩存取一個發送，填滿窗口。準確的說，CMPP協議中定義的滑動窗口概念不準確，應該叫縮放窗口。因爲它並沒有實現序列控制問題，只是起到流量控制和異步高效快速發送的目的。相對於Stop-Wait機制來說的。
（5）重複丟棄機制。如果接受到的MO消息是一條重複的，就丟棄這條消息，不能將這條MO消息交給上層。如何判斷是重複的呢？通過每條消息的序列號。當然如果網關不維持這個序列號的唯一性和有序性，你只能乾瞪眼。
（6）上接口緩存和回收隊列。從上層接受短消息，保存到緩存裏，這個緩存不要做的太大，超過一定量時，讓上層發送短消息接口阻塞。而將緩存技術單獨用一個模塊來實現。回收隊列是儲存每個鏈路崩潰時，處於滑動窗口中等待應答的消息。
（7）有序控制機制。是保障先來的消息，先發送出去，後來的後發，嚴格地保障先後順序。是通過序列號和滑動窗口來保障的。實際應用中，倒是不那麼嚴格地關注順序發送問題。

以上7點是這個協議模塊的核心問題。如果，一個CMPP協議模塊沒有解決這些問題，那是一個殘缺不全的實現，上不了桌面的東西。