（計算機科學與技術專業(yè)論文）xxxx衛(wèi)星實時傳輸子系統(tǒng)的設計與實現(xiàn).pdf

獨創(chuàng)性( 或創(chuàng)新性) 聲明 本人聲明所呈交的論文是本人在導師指導下進行的研究工作及取得的研究 成果。盡我所知，除了文中特別加以標注和致謝中所羅列的內(nèi)容以外，論文中不 包含其他人已經(jīng)發(fā)表或撰寫過的研究成果，也不包含為獲得北京郵電大學或其他 教育機構(gòu)的學位或證書而使用過的材料。與我一同工作的同志對本研究所做的任 何貢獻均已在論文中作了明確的說明并表示了謝意。 申請學位論文與資料若有不實之處，本人承擔一切相關責任。 本人簽名：邵歪之 同期： 關于論文使用授權的說明 學位論文作者完全了解北京郵電大學有關保留和使用學位論文的規(guī)定，即： 研究生在校攻讀學位期間論文工作的知識產(chǎn)權單位屬北京郵電大學。學校有權保 留并向國家有關部門或機構(gòu)送交論文的復印件和磁盤，允許學位論文被查閱和借 閱；學?？梢怨紝W位論文的全部或部分內(nèi)容，可以允許采用影印、縮印或其它 復制手段保存、匯編學位論文。( 保密的學位論文在解密后遵守此規(guī)定) 非保密論文注釋：本學位論文不屬于保密范圍，適用本授權書。 本人簽名：翻二杰叁日期： 導師簽名： 沙| o 、弓、| o 日期：絲! ! ：羅：! ! x x x x 衛(wèi)星實時傳輸子系統(tǒng)的設計與實現(xiàn) 摘要 x x x x 衛(wèi)星地面通信系統(tǒng)承擔著衛(wèi)星原始資料、衛(wèi)星測控和軌道數(shù) 據(jù)、指揮調(diào)度信息等數(shù)據(jù)的遠程傳輸任務，對我國的x x x x 衛(wèi)星事業(yè)有 著舉足輕重的作用。其中，通信分系統(tǒng)主要負責實時高效、安全穩(wěn)定 的衛(wèi)星原始數(shù)據(jù)傳輸工作。通信分系統(tǒng)應用軟件劃分為兩個子系統(tǒng)： 實時傳輸子系統(tǒng)( x x x x o i ) 、通信設備監(jiān)控子系統(tǒng)( ) 【) 【x x 0 2 ) 。實時傳 輸子系統(tǒng)主要提供轉(zhuǎn)發(fā)端至接收端的高效的可靠的數(shù)據(jù)文件的傳輸 功能；通信設備監(jiān)控子系統(tǒng)用于實現(xiàn)調(diào)制解調(diào)器路由器、通信收發(fā) 器和調(diào)制解調(diào)器等通信設備的遠程監(jiān)控和告警消息的發(fā)送功能。其 中，實時傳輸子系統(tǒng)運行在轉(zhuǎn)發(fā)端和接收端的u n i x 通信服務器上，通 信設備監(jiān)控子系統(tǒng)運行在轉(zhuǎn)發(fā)端和接收端的監(jiān)控w i n d o w sp c 上。實時 傳輸子系統(tǒng)能為整個通信分系統(tǒng)提供高效可靠的數(shù)據(jù)傳輸。 論文針對現(xiàn)有實時傳輸子系統(tǒng)的實際需求，在分析與研究通信模 型的基本理論和方法的基礎上，提出并建立了實時傳輸子系統(tǒng)的通信 模型，給出了實時傳輸子系統(tǒng)的總體結(jié)構(gòu)設計，并基于此通信模型， 詳細闡述了實時傳輸子系統(tǒng)發(fā)送端和接收端的功能設計和通信接口 及通信協(xié)議的設計，包括模塊劃分、模塊交互的內(nèi)部接口、模塊功能 實現(xiàn)、系統(tǒng)間交互的外部接口等。根據(jù)以上的系統(tǒng)設計，將該實時傳 輸子系統(tǒng)在u n i x 平臺下編程實現(xiàn)。 根據(jù)實際應用需求，對實時傳輸子系統(tǒng)進行了系統(tǒng)地測試，測試 結(jié)果表明該系統(tǒng)能夠滿足整個衛(wèi)星通信系統(tǒng)對其的功能需求及性能 需求。論文還針對該實時傳輸子系統(tǒng)的優(yōu)化提出了相關建議。 關鍵詞：實時傳輸通信模型消息隊列多線程u n i x 北京郵i 【1 人學頌i ：學位論文 t h ed e s i g na n di m p l e m e n t a t i o no f x x x xs a t e l l i t er e a i t i m e t r a n s m i s s i o ns u b s y s t e m a b s t r a c t t h ex x x xs a t e l l i t eg r o u n dc o m m u n i c a t i o ns y s t e mi s r e s p o n s i b l ef o rt h e t r a n s m i s s i o no fo r i g i n a ls a t e l l i t ed a t a ，t h em e a s u r e m e n ta n dc o n t r o ld a t aa n dt h e d i s p a t c hc o m m a n d t h i ss y s t e mp l a y sav i t a lr o l ei nt h ex x x x s a t e l l i t ec a r e e ro fo u r n a t i o n a sap a r to ft h es y s t e m ，t h ec o m m u n i c a t i o ns u b s y s t e ma i m sa tm a k i n g r e a l - t i m e ，e f f i c i e n t ，s e c u r ea n ds t a b l et r a n s m i s s i o no fo r i g i n a ls a t e l l i t ed a t ab e t w e e n d i f f e r e n ts i t e s t h ec o m m u n i c a t i o ns u b s y s t e mi sd i v i d e di n t ot w op a r t s ：t h er e a l - t i m e t r a n s m i s s i o n s u b s y s t e m ( x x x x 0 1 ) ，w h i c hp r o v i d e s e f f i c i e n ta n dr e l i a b l e t r a n s m i s s i o nf u n c t i o n a l i t yf r o mr e l a yt or e c e i v e rs i t e ；t h ec o m m u n i c a t i o ne q u i p m e n t s u r v e i l l a n c e s u b s y s t e m ( x x x x 0 2 ) ，w h i c h e n a b l e sr e m o t es u r v e i l l a n c ea n d n o t i f i c a t i o nm e s s a g ef o rm o d e m ，m u t e r ，c o m m u n i c a t i o nt r a n s c e i v e re q u i p m e n t t h e r e a l - t i m et r a n s m i s s i o ns u b s y s t e mi sr u n n i n go nu n i xc o m m u n i c a t i o ns e r v e ri n s t a l l e d i nr e l a ya n dr e c e i v e rs i t e ，a n dt h ec o m m u n i c a t i o ne q u i p m e n ts u r v e i l l a n c es u b s y s t e m t a k e sw i n d o w sp ca si t sr u n n i n ge n v i r o n m e n t t h er e a l t i m et r a n s m i s s i o ns u b s y s t e m 啪p r o v i d ee f f i c i e n td a t at r a n s m i s s i o nf o rt h ew h o l ec o m m u n i c a t i o ns u b s y s t e m b a s e do nt h e a n a l y s i sa n dr e s e a r c h t ot h eb a s i c t h e o r ya n dm e t h o do f c o m m u n i c a t i o nm o d e l s ，a c c o r d i n gt ot h ea c t u a l r e q u i r e m e n t s o ft h er e a l - t i m e t r a n s m i s s i o ns u b s y s t e m ，w eb r i n gf o r w a r da n de s t a b l i s ht h ec o m m u n i c a t i o nm o d e lo f t h er e a l - t i m et r a n s m i s s i o ns u b s y s t e m ，g i v eg e n e r a ls t r u c t u r ed e s i g no ft h es y s t e m ，a n d b a s e do nt h ec o m m u n i c a t i o nm o d e l ，w ee x p l a i nt h ef u n c t i o nd e s i g no ft h et r a n s m i t t e r a n dr e c e i v e ra n dt h ed e s i g no fc o m m u n i c a t i o ni n t e r f a c e sa n dc o m m u n i c a t i o n p r o t o c o l sw h i c hi n c l u d em o d u l ed e v i s i o n ，i n n e ri n t e r f a c eo fm o d u l el e v e li n t e r a c t i o n ， i m p l e m e n t a t i o no ft h em o d u l ef u n c t i o n ，o u t e ri n t e r f a c eo fs y s t e ml e v e li n t e r a c t i o na n d s oo n a c c o r d i n gt oa b o v es y s t e md e s i g n ，w ei m p l e m e n tt h er e a l - t i m et r a n s m i s s i o n s u b s y s t e mu n d e ru n i xp l a t f o r m a c c o r d i n gt ot h ea c t u a la p p l i c a t i o nr e q u i r e m e n t s ，w ei m p l e m e n tas y s t e m a t i c a l t e s tt 0t h er e a l t i m et r a n s m i s s i o ns u b s y s t e mw h o s e r e s u l ts h o w st h a tt h es u b s y s t e m h 鶴f u l f i l l e db o t hf u n c t i o n a l i t yr e q u i r e m e n t sa n dp e r f o r m a n c er e q u i r e m e n t s r e q u i r c d b yt h ew h o l es a t e l l i t ec o m m u n i c a t i o ns y s t e m f i n a l l y ，w eg i v es o m ea d v i c eo nt h e o p t i m i z a t i o no ft h er e a l t i m et r a n s m i s s i o ns u b s y s t e m k e yw o r d s ：r e a l - t i m et r a n s m i s s i o n ，c o m m u n i c a t i o n m o d e l ，m e s s a g e q u e u e ，m u l t i t h r e a d ，u n i x 北京i t l l _ i d j , 人學碩i ：學位論文 目錄 第一章緒論1 1 1 課題背景1 1 2 課題研究的目的和意義2 1 3 課題的主要研究內(nèi)容2 第二章通信模型及相關技術4 2 1 通信模型分析4 2 1 1 實體工作模式4 2 1 2 面向連接與面向非連接的傳輸方式6 2 1 3 服務確認方式7 2 2 進程間通信方式的比較9 2 3 消息隊列技術的設計模式1 0 2 4s o c k e t 網(wǎng)絡編程n 2 5 刪ix 下多線程編程1 2 第三章需求分析1 3 第四章實時傳輸子系統(tǒng)的設計與實現(xiàn)1 6 4 1 實時傳輸子系統(tǒng)模型設計1 6 4 1 1 采用主從模式1 6 4 1 2 采用面向連接的傳輸方式1 6 4 。1 3 系統(tǒng)采用的服務確認方式1 7 4 1 4 實時傳輸子系統(tǒng)模型1 7 4 1 5 發(fā)送端和接收端的交互協(xié)議1 9 4 1 6 消息傳輸系統(tǒng)。2 l 4 2 實時傳輸子系統(tǒng)中的基本概念2 7 4 3 實時傳輸子系統(tǒng)的概要及詳細設計3 0 4 3 1 系統(tǒng)總體架構(gòu)3 0 4 3 2 接收端處理程序概要及詳細設計3 4 4 3 3 發(fā)送端處理程序概要及詳細設計4 8 第五章系統(tǒng)測試6 l 5 1 環(huán)境介紹6 1 5 2 測試方案及結(jié)果介紹6 l 第六章總結(jié)和展望6 9 參考文獻7 0 致謝7 2 攻讀學位期間發(fā)表的學術論文目錄7 3 北京郵i 【1 人學頒l ：學位論文 1 1 課題背景 第一章緒論 x x x x 衛(wèi)星地面應用系統(tǒng)是一個實時、多功能的遙感衛(wèi)星的業(yè)務運行系統(tǒng)。 其主要目的是完成對x x x x 衛(wèi)星( 和或其他遙感衛(wèi)星) 遙感數(shù)據(jù)接收、數(shù)據(jù)遠 程傳輸、數(shù)據(jù)預處理、產(chǎn)品制作、數(shù)據(jù)存檔和產(chǎn)品分發(fā)、定標和真實性檢驗、產(chǎn) 品應用和示范等業(yè)務處理工作，為各類用戶提供x x x x 衛(wèi)星遙感數(shù)據(jù)產(chǎn)品與服 務。 該系統(tǒng)由以下幾個分系統(tǒng)組成：接收預處理分系統(tǒng)；資料處理分系統(tǒng)；資料 存檔與產(chǎn)品分發(fā)分系統(tǒng)；輻射定標和真實性檢驗分系統(tǒng)；產(chǎn)品應用與示范分系統(tǒng)； 通信分系統(tǒng)；運控分系統(tǒng)。 通信分系統(tǒng)承擔著衛(wèi)星遙感數(shù)據(jù)傳輸、網(wǎng)絡監(jiān)控以及傳輸信道切換的任務， 以保證x x x x 地面站遙感數(shù)據(jù)高可靠、實時傳輸和網(wǎng)絡監(jiān)控，該分系統(tǒng)是整個地 面應用系統(tǒng)的“通信中樞 。該分系統(tǒng)由若干臺高可用性計算機系統(tǒng)、高性能網(wǎng) 絡和各種通信設備以及“x x x x 衛(wèi)星地面應用系統(tǒng)通信分系統(tǒng)應用軟件子系統(tǒng) 組成。 通信分系統(tǒng)應用軟件劃分為兩個子系統(tǒng)：實時傳輸子系統(tǒng)( x x x x 0 1 ) 、通 信設備監(jiān)控子系統(tǒng)( x x x x 0 2 ) 。實時傳輸子系統(tǒng)主要提供發(fā)送端至接收端的高 效的可靠的數(shù)據(jù)文件的傳輸功能；通信設備監(jiān)控子系統(tǒng)用于實現(xiàn)調(diào)制解調(diào)器路 由器、通信收發(fā)器和調(diào)制解調(diào)器等通信設備的遠程監(jiān)控和告警消息的發(fā)送功能。 其中，實時傳輸子系統(tǒng)運行在發(fā)送端和接收端的u n i x 通信服務器上，通信設備 監(jiān)控予系統(tǒng)運行在發(fā)送端和接收端的監(jiān)控w i n d o w sp c 上。 發(fā)送端接收端之間的通信信道采用光纖和v s a t 兩條專線的主備工作方式。 實時傳輸子系統(tǒng)分為發(fā)送端實時傳輸子系統(tǒng)和接收端實時傳輸子系統(tǒng)。接收 端實時傳輸子系統(tǒng)主要通過光纖鏈路和發(fā)送端實時傳輸子系統(tǒng)進行通信，在光纖 鏈路故障狀態(tài)下采用備用的衛(wèi)星鏈路進行通信。每個實時傳輸子系統(tǒng)需要與本地 的通信設備監(jiān)控子系統(tǒng)通信。實時傳輸子系統(tǒng)將傳輸狀態(tài)、告警信息等傳遞給通 信設備監(jiān)控子系統(tǒng)并加以顯示。 根據(jù)本系統(tǒng)的設計需求，概括出實時傳輸子系統(tǒng)的設計目標如下： 1 、在光纖鏈路正常的情況下，實現(xiàn)高效的實時傳輸，并按優(yōu)先級分配各個 實時衛(wèi)星數(shù)據(jù)的傳輸帶寬； 2 、在光纖鏈路斷開的情況下，采用衛(wèi)星鏈路實現(xiàn)高效的數(shù)據(jù)文件的傳輸； 北京郵i u 人學壩i ：學位論文 3 、有效判斷鏈路是否擁塞，能在重新啟動后實現(xiàn)斷點續(xù)傳； 4 、按要求實現(xiàn)傳輸狀念和異常狀態(tài)的即時報告； 5 、整個系統(tǒng)能高效、穩(wěn)定、可靠地運行。 實時傳輸子系統(tǒng)( x x x x 0 1 ) 拓撲圖如下： 星數(shù)據(jù) 接收端數(shù)據(jù)記錄p c 發(fā)送端b 數(shù)據(jù)記錄p c 圖1 - 1 實時傳輸子系統(tǒng)拓撲圖 1 2 課題研究的目的和意義 務器 本次研究具有重要的意義，可以設計并實現(xiàn)實時傳輸子系統(tǒng)，實現(xiàn)傳輸任務 調(diào)度、實時數(shù)據(jù)靜態(tài)備份：數(shù)據(jù)傳輸狀態(tài)報告、數(shù)據(jù)傳輸狀態(tài)監(jiān)視、工作日志等 功能，使光纖和衛(wèi)星鏈路共同協(xié)作，保證衛(wèi)星數(shù)據(jù)的高效可靠的傳輸，為整個 x x x x 衛(wèi)星通信分系統(tǒng)起到中問橋梁的作用，最終為各類用戶提供衛(wèi)星遙感數(shù)據(jù) 產(chǎn)品與服務，并為以后的系統(tǒng)擴展打好基礎。 1 3 課題的主要研究內(nèi)容 為了實現(xiàn)x x x x 衛(wèi)星實時傳輸子系統(tǒng)網(wǎng)絡數(shù)據(jù)的高效可靠傳輸，我們分析現(xiàn) 有模型及技術，并結(jié)合項目需求，設計適合本系統(tǒng)的模型，并在u n i x 平臺下實 現(xiàn)，最后，對系統(tǒng)的功能和性能等進行了測試。 2 第一章緒論，介紹了課題背景，提出了本課題研究的目的和意義，并介紹了 課題的主要研究內(nèi)容。 第二章通信模型及相關技術，該章對通信模型的通信模式( 對稱通信和非對 稱通信) 、傳輸方式( 面向連接和無連接) 和對話模式等進行了比較分析，詳細 了解它們的原理及優(yōu)缺點。還對本項目中應用到的技術進行了分析。 第三章需求分析，對本項目的用戶需求進行了介紹和分析，包括功能和性能 的需求等。 第四章系統(tǒng)設計與實現(xiàn)，該章根據(jù)實時傳輸子系統(tǒng)的需求，對其進行交互模 型的分析，設計發(fā)送端和接收端的交互協(xié)議，設計交互接口以及各端對數(shù)據(jù)的處 理方法。對系統(tǒng)進行設計，包括基本組成要素的設計，系統(tǒng)框架的概要設計，以 及系統(tǒng)的詳細設計。根據(jù)以上的系統(tǒng)設計，將此實時傳輸子系統(tǒng)在u n i x 平臺下 編程實現(xiàn)。 第五章系統(tǒng)測試，利用各類數(shù)據(jù)，對實時傳輸子系統(tǒng)進行測試，經(jīng)過分析， 它已經(jīng)滿足預期的功能和性能要求，以此對系統(tǒng)的設計進行驗證。 第六章總結(jié)與展望，該章對本課題的研究工作和論文進行了總結(jié)評價，并對 后續(xù)工作進行了展望。對以上系統(tǒng)的設計和實現(xiàn)進行分析，不足的地方有待以后 改進。另外，一些在當前項目中尚未實現(xiàn)的功能，也有待在以后的開發(fā)工作中在 已實現(xiàn)系統(tǒng)的基礎上增加并實現(xiàn)，逐步完善整個系統(tǒng)。 3 北京郵i 【1 人學碩i ：學位論義 第二章通信模型及相關技術 2 1 通信模型分析 2 1 1 實體工作模式 1 、主從模式 圖2 - 1 主從模式 如上圖，主從模式有一個主站、一個或多個次站，主站和次站的地位不對等， 雙方的信息流是不一樣的，主站只可以作為主站，不可以轉(zhuǎn)化為次站，次站亦不 可以轉(zhuǎn)化為主站。主站可以向次站發(fā)送命令消息，而次站則不可向主站發(fā)送命令 消息，只可以發(fā)送響應消息。對于c s 結(jié)構(gòu)的應用，就應該采用這種工作模式。 2 、平衡模式 命令 響應 圖2 - 2 平衡模式 如上圖，平衡模式中，各站地位是對等的。每個站都既是主站，又是次站， 每個站都可以發(fā)送命令消息和接收響應消息，也可以接收命令消息和發(fā)送響應消 4 北京郵i l 1 人學碩i ：學位論文 息。主從模式并不能適用于所有場合，對于各站地位對等的各項應用，就需要采 用平衡工作模式。 比如，我們來分析一下c p i c 。 c p i c 就是c o m m o np r o g r a m m i n gi n t e r f a c e c o m m u n i c a t i o n s ( 通用程序通信接 口) ，它與a p p c ( a d v a n c e dp r o g r a mt op r o g r a mc o m m u n i c a t i o n ，先進程序間通 信) 相聯(lián)系。a p p c 沒有提供通用的應用編程接口，不能跨平臺，必須為不同系 統(tǒng)編寫不同的代碼。c p i c 幫助a p p c 解決了這個問題，它是一個子程序包，有一 套通用的代碼，實現(xiàn)了跨平臺。c p i c 是一個同步的通信模式，采用雙向交互。 進行通信的某一方程序首先發(fā)起一次對話請求，并且它可以控制信息的流劫，如 下圖。然后，對話發(fā)起者可以向?qū)Ψ匠绦虬l(fā)送數(shù)據(jù)，而對方程序則可接收數(shù)據(jù)。 接收方在收到數(shù)據(jù)之后，可向發(fā)送方發(fā)送確認信息，發(fā)起方接收此信息。消息收 發(fā)完成后，此次對話的發(fā)起方斷開此次連接，本次對話結(jié)束。 a b 圖2 - 3 使用c p i - c 的基于連接的同步通信方式 進行對話通信的程序雙方必須跟蹤對話的狀態(tài)，以備發(fā)生故障時，對原對話 進行恢復。在整個對話過程中，對話雙方都必須同時參加對話，不能進行其他操 作。如果由于某種原因，連接斷開，那么就由對話發(fā)起者重建并恢復此次對話。 由上圖可見，通信雙方其實也可處于對等地位，a 發(fā)起并控制一次對話，那么在 此次對話結(jié)束后，b 同樣也可以發(fā)起并控制另一次對話。這就表示c p i c 既支持 主從模式，也支持平衡模式【。 5 北京郵i u 人學順i j 學位論文 根據(jù)以上分析，在設計系統(tǒng)時，需要根據(jù)實際的需求來確定使用主從模式還 是平衡模式。 2 1 2 面向連接與面向非連接的傳輸方式 1 、t c p t c p ( 傳輸控制協(xié)議) 提供的是面向連接、可靠的字節(jié)流服務。當客戶和服 務器彼此交換數(shù)據(jù)前，必須先在雙方之間建立一個t c p 連接，之后才能傳輸數(shù)據(jù)。 t c p 提供超時重發(fā)，丟棄重復數(shù)據(jù)，數(shù)據(jù)檢驗，流量控制等功能，保證數(shù)據(jù)正確 的從一端傳到另一端。t c p 的目的是提供可靠的數(shù)據(jù)傳輸。t c p 在數(shù)據(jù)包接收無 序、丟失或在交付期間被破壞時，負責數(shù)據(jù)恢復。它通過為其發(fā)送的每個數(shù)據(jù)包 提供一個序號來完成此恢復。較低的網(wǎng)絡層會將每個數(shù)據(jù)包視為一個獨立的單 元，因此，數(shù)據(jù)包可以沿著完全不同的路徑發(fā)送，即使它們都是同一消息的組成 部分。這種路由與網(wǎng)絡層處理分段和重組數(shù)據(jù)包的方式非常相似，只是級別更高 而已。 為確保正確地接收數(shù)據(jù)，t c p 要求在目標計算機成功收到數(shù)據(jù)時發(fā)回一個確 認( 即a c k ) 。如果在某個時限內(nèi)未收到相應的a c k ，將重新傳送數(shù)據(jù)包。如果 網(wǎng)絡擁塞，這種重新傳送將導致發(fā)送的數(shù)據(jù)包重復。但是，接收計算機可使用數(shù) 據(jù)包的序號來確定它是否為重復數(shù)據(jù)包，并在必要時丟棄它。 2 、u d p u d p ( 用戶數(shù)據(jù)報協(xié)議) 是一個簡單的面向數(shù)據(jù)報的傳輸層協(xié)議。u d p 不提 供可靠性，它只是把應用程序傳給網(wǎng)絡層的數(shù)據(jù)報發(fā)送出去，但是并不保證它們 能到達目的地。由于u d p 在傳輸數(shù)據(jù)報前不用在客戶和服務器之間建立一個連 接，且沒有超時重發(fā)等機制，故而傳輸速度很快。 u d p 與t c p 的主要區(qū)別在于u d p 不一定提供可靠的數(shù)據(jù)傳輸。事實上，該 協(xié)議不能保證數(shù)據(jù)準確無誤地到達目的地。但是，u d p 在許多方面非常有效。 當某個程序的目標是盡快地傳輸盡可能多的信息時，可使用u d p 。 3 、t c p 和u d p 的選擇 當數(shù)據(jù)傳輸?shù)男阅鼙仨氉屛挥跀?shù)據(jù)傳輸?shù)耐暾?、可控制性和可靠性時， t c p 協(xié)議是當然的選擇。當強調(diào)傳輸性能而不是傳輸?shù)耐暾詴r，如：音頻和多 媒體應用，u d p 是最好的選擇。在數(shù)據(jù)傳輸時間很短，以至于此前的連接過程成 為整個流量主體的情況下，u d p 也是一個好的選擇，如：d n s 交換。把s n m p 建 立在u d p 上的部分原因是設計者認為當發(fā)生網(wǎng)絡阻塞時，u d p 較低的開銷使其有 更好的機會去傳送管理數(shù)據(jù)。 6 北京郵l 也人學顧i ：學位論文 2 1 3 服務確認方式 不o 1 、無確認方式 無確認方式是指對于一方發(fā)出的請求消息，對方都不予回復確認。如下圖所 圖2 - 4 無確認方式 如上圖，a 端發(fā)出的所有消息，b 端接收之后都不進行回復。這種方式節(jié)省 傳輸所需的總時間，但是安全性不高。 2 、部分確認方式 部分確認方式是指對于一方發(fā)出的請求消息，接收方只對其中的一部分進行 確認。如下圖所示。 圖2 - 5 部分確認方式 如上圖，對于a 端發(fā)出的所有請求消息，接收端b 對于其中較重要的一部分 數(shù)據(jù)進行回復，其他的部分不予回復。這種方式由于要發(fā)送回復消息，所以多花 費了時間，但是在一定程度上提高了數(shù)據(jù)傳輸?shù)陌踩浴?3 、完全確認方式 完全確認方式是指對于一方發(fā)出的請求消息，接收方全部予以確認。如下圖 所示。 7 北京郵i 【1 人學煩l ：學位論文 圖2 - 6 完全確認方式 如上圖，對于a 端發(fā)出的所有請求消息，接收端b 都予以回復確認。這種方 式花費時間最多，但是安全性最好。 比如r p c 。r p c ( 遠程過程調(diào)用) 是一種c s 的編程模式，調(diào)用者和被調(diào)用 者關系是固定的，很難實現(xiàn)對等通信。它跨越了傳輸層和應用層，本質(zhì)是實現(xiàn)網(wǎng) 絡七層協(xié)議中的會話層的功能。r p c 是一種同步的、對話方式的模型，如下圖所 示。 a 圖2 - 7 使用r p c 的基于連接的同步通信方式 對于r p c ，請求服務的程序就是客戶端，服務提供者就是服務器。首先，客 戶端的一個調(diào)用程序發(fā)送一個服務請求給服務器端，然后進入等待狀態(tài)，等待服 務端的回復消息。服務器端接收到服務請求消息，獲得請求參數(shù)，進行處理，計 算結(jié)果，然后向客戶端發(fā)送答復消息，然后進入睡眠狀態(tài)，直到下一個服務請求 消息到達為止?？蛻舳私邮盏椒掌鞫说幕貜拖?，獲取計算結(jié)果，然后繼續(xù)執(zhí) 8 北京郵i 【1 人學碩i ：學位論文 行下面的程序【引。這就是一個完全確認的例子。 2 2 進程間通信方式的比較 管道( p i p e ) 是一種半雙工的通信方式，數(shù)據(jù)只能單向流動，而且只能在具 有親緣關系的進程問使用。進程間的親緣關系通常是指父子進程關系。 有名管道( n a m e dp i p e ) 也是半雙工的通信方式，但是它允許無親緣關系的 進程問的通信。與進程持續(xù)，內(nèi)容隨進程消失而消失。 信號量( s e m o p h o r e ) 是一個計數(shù)器，可以用來控制多個進程對共享資源的 訪問。它常被作為一種鎖機制，防止某進程正在訪問共享資源時，其他進程也來 訪問該資源。因此，信號量主要作為進程間以及同一進程內(nèi)不同線程之間的同步 手段。 信號( s i g n a l ) 是一種比較復雜的通信方式，用于通知接收進程某個事件已 經(jīng)發(fā)生。 共享內(nèi)存( s h a r e dm e m o r y ) 就是映射一段能被其他進程所訪問的內(nèi)存，這 段共享內(nèi)存由一個進程創(chuàng)建，但多個進程都可以訪問。共享內(nèi)存是最快的i p c 方 式，它是針對其他進程間通信方式運行效率低的不足而專門設計的。它往往與其 他通信機制( 如信號量) 配合使用，來實現(xiàn)進程間的同步通信。寫入共享內(nèi)存的 東西是一直存在的，主要用于共享大數(shù)據(jù)文件。 鑒于本項目的需求分析，共享內(nèi)存不適合用來當做整體通信模型。 消息隊列( m e s s a g eq u e u e ) 是由消息組成的鏈表，存放在內(nèi)核中，并由消息 隊列標識符來標識。消息隊列提供有格式字節(jié)流，具有類型及優(yōu)先級別，克服了 信號傳遞信息少、管道及有名管道只能承載無格式字節(jié)流等缺點，更簡單、安全、 靈活，應用空間更大。一旦有進程把消息讀出消息隊列，此消息就不會繼續(xù)存在 于消息隊列中，它其實起到“信箱”的作用。消息隊列和共享內(nèi)存一樣，都是隨 內(nèi)核持續(xù)的，進程消失時，如果不是明確刪除該i p c 對象，它們并不會消失，只 有重啟機器才會使它們消失。消息隊列常駐內(nèi)存，可靠且通信效率高。 消息隊列為程序提供了一種異步通信方式。一個程序以一個消息隊列作為中 轉(zhuǎn)與另一個程序進行相互通信，其中，這個消息隊列相對于此程序來說，可以是 本地的，也可以是遠程的。如下圖。 9 北京郵i 【1 人學f ! ； i ：學位論義 。l p u t ( q u e u eb ) y l 1 q u e u eb g e t ( q u e u eb ) m ( q 二u eb ) g e t ( q u e u ea )p u t ( q u e u ea ) o u e u e a r 圖2 - 8 基于消息隊列的異步通信方式 比如，程序a 和程序b 通過消息隊列進行通信，它們都有自己的一個消息隊 列。程序a 只需要p u t 一條消息到與b 相關聯(lián)的消息隊列上，然后程序a 就可以干 別的事情。在程序a 向消息隊列p u t 消息的時候，程序b 可以進行其他的處理， 或者也可以未在運行，有時間或者需要的時候再到與之相關聯(lián)的消息隊列上g e t 一條消息進行處理即可。它們都幾乎感覺不到通信的發(fā)生。而且，一個程序可以 通過向不同的消息隊y 1 p u t 消息來實現(xiàn)與多個應用程序的通信。 套接字( s o c k e t ) 也是一種進程間通信機制，但是與其他通信機制不同的是， 它可以用于不同機器間的進程通信。s o c k e t 通信采用的是客戶服務器模式，即客 戶向服務器發(fā)出連接請求，服務器接收到請求之后接受，連接建立。 通過比較上面的幾種u n i x 進程間通信方式，針對本項目的需求，我們選擇 消息隊列通信機制。 2 3 消息隊列技術的設計模式 1 、異步查詢：客戶端可以向服務器端查詢信息，但是不需要等待確認消息 就可以繼續(xù)往下執(zhí)行。當確認消息達到時，由專門的處理程序接收并做相應處理。 所以，客戶端處于完全異步的方式工作。這是標準的查詢過程，如果失敗，客戶 端可重復發(fā)送請求。這種設計模式簡單可靠，為查詢應用程序廣泛采用。 2 、偽同步查詢：客戶端可以向服務器發(fā)送查詢請求，并等待查詢結(jié)果返回， 但是客戶端并不會永久的去等待。此方式有兩個特點，一是客戶端是同步工作的， 二是如果失敗，客戶端可以重復發(fā)送請求。此模式難點在于如何確定確認消息的 超時。 1 0 北京郵i 【1 人學顧i ：學位論義 3 、異步確認更新：客戶端可以向服務器進行更新的操作，在確認消息到達 之前可以繼續(xù)執(zhí)行下面的操作。此模式應用廣泛，但設計難度較大。 4 、無確認更新：客戶端可以對服務器更新數(shù)據(jù)，卻不需要等待確認消息。 5 、偽同步更新：客戶端可以向服務器進行更新的操作，并等待更新操作的 執(zhí)行結(jié)果。更新操作可以失敗，但是客戶端必須有處理失敗的機制。 通過比較這幾種消息隊列的設計模式，結(jié)合本項目的需求，我們采用無確認 更新的模式。 2 4s o c k e t 網(wǎng)絡編程 s o c k e t 通信是網(wǎng)間進程問的通信，即不同主機進程間的相互通信問題( 可把 同機進程通信看做是其中的實例) 。s o c k e t 通信的不同主機間的進程采用端口進行 標識。端口是操作系統(tǒng)可分配的一種資源。類似于文件描述符，每個端口都擁有 一個叫端口號的整數(shù)型標識符，用于區(qū)別不同端口。 s o c k e t 通信采用的是客戶服務器模式，即客戶向服務器發(fā)出連接請求，服務 器接收到請求之后接受，連接建立。下面具體說明一下通信過程。 首先，創(chuàng)建套接字s o c k e t ( ) 。服務器在使用套接字之前，首先必須擁有 一個套接字，系統(tǒng)調(diào)用s o c k e t ( ) 函數(shù)向應用程序提供創(chuàng)建套接字的手段。 指定本地地址b i n d ( ) 。當一個套接字用s o c k e t ( ) 創(chuàng)建之后，存在一個 名字空間，但它沒有被命名。b i n d ( ) 將套接字地址( 包括本地主機地址和本地 端口地址) 與所創(chuàng)建的套接字號聯(lián)系起來，即將名字賦予套接字，以指定本地半 相關。 監(jiān)聽連接l i s t e n ( ) 。它由服務器調(diào)用，表示它愿意接收連接，l i s t e n ( ) 需要在a c c e p t ( ) 之前調(diào)用。 建立套接字連接c o 仰e c t ( ) 和a c c e p t ( ) 。這兩個系統(tǒng)調(diào)用用于完成一 個完整相關的建立，其中c o n n e c t ( ) 用于建立連接。a c c e p t ( ) 用于使服務器等 待來自某客戶進程的實際連接。 數(shù)據(jù)傳輸1 e n d ( ) 和r e c v ( ) 。當一個連接建立之后，就可以傳輸數(shù)據(jù)了。 s e n d ( ) 用于發(fā)送數(shù)據(jù)，r e c v ( ) 用于接收數(shù)據(jù)。 關閉套接字刊o s e s o c k e t ( ) 。此調(diào)用用于關閉一個套接字，并釋放分配 給它的資源，如果此套接字涉及到一個打開的t 印連接，則該連接被釋放。 服務器調(diào)用過程：s o c k e t ( ) b i n d ( ) l i s t e n ( ) a c c e p t ( ) r e c v( )或s e n d( ) c l o s e s o c k e t( ) 。 客戶端調(diào)用過程：c o n n e c t ( ) s e n d ( ) 或r e c v ( ) c l o s e s o c k e t ( ) o 北京郵i 乜人學頌i ：學位論義 2 5u n i x 下多線程編程 和進程相比，使用多線程是一種非?！惫?jié)儉”的多任務操作方式。在u n i x 系 統(tǒng)下，啟動一個新的進程，必須分配給它獨立的地址空間，建立眾多的數(shù)據(jù)表來 維護它的代碼段、堆棧段和數(shù)據(jù)段，這是一種”昂貴”的多任務工作方式。而運行 于一個進程中的多個線程，它們彼此之間使用相同的地址空間，共享大部分數(shù)據(jù)， 啟動一個線程所花費的空間遠遠小于啟動一個進程所花費的空問，而且，線程間 彼此切換所需的時間也遠遠小于進程間切換所需要的時間。據(jù)統(tǒng)計，總的說來， 一個進程的開銷大約是一個線程開銷的3 0 倍左右，當然，在具體的系統(tǒng)上，這個 數(shù)據(jù)可能會有較大的區(qū)別。 使用多線程的第二個好處是線程間擁有方便的通信機制。對不同進程來說， 它們具有獨立的數(shù)據(jù)空間，要進行數(shù)據(jù)的傳遞只能通過通信的方式進行，這種方 式不僅費時，而且很不方便。線程則不然。由于同一進程下的線程之間共享數(shù)據(jù) 空間，所以一個線程的數(shù)據(jù)可以直接為其它線程所用，這不僅快捷，而且方便。 當然，數(shù)據(jù)的共享也帶來其他一些問題，有的變量不能同時被兩個線程所修改， 有的子程序中聲明為s t a t i c 的數(shù)據(jù)更有可能給多線程程序帶來災難性的打擊，這 些正是編寫多線程程序時最需要注意的地方。 上面是和進程比較的優(yōu)勢，另外，多線程程序作為一種多任務、并發(fā)的工作 方式，有以下一些優(yōu)點： 1 ) 提高應用程序響應。當一個操作耗時很長時，整個系統(tǒng)都會等待這個操 作，此時程序不會響應其他的操作，而使用多線程技術，將耗時長的操作置于一 個新的線程，可以避免這種尷尬的情況。 2 ) 使多c p u 系統(tǒng)更加有效。操作系統(tǒng)會保證當線程數(shù)不大于c p u 數(shù)目時， 不同的線程運行于不同的c p u 上。 3 ) 改善程序結(jié)構(gòu)。一個既長又復雜的進程可以考慮分為多個線程，成為幾 個獨立或半獨立的運行部分，這樣的程序會利于理解和修改。 u n i x 系統(tǒng)下的多線程遵循p o s i x 線程接口，稱為p t h r e a d 。編寫u n i x 下的多 線程程序，需要使用頭文件p t h r e a d h ，連接時需要使用庫l i b p t h r e a d a 。 多線程編程是一個很有意思也很有用的技術，使用多線程技術的網(wǎng)絡螞蟻是 目前最常用的下載工具之一，使用多線程技術的g r e p 比單線程 拘g r e p 要快上幾倍， 類似的例子還有很多。利用多線程技術可以寫出高效實用的好程序來。 接收端實時傳輸子系統(tǒng)與發(fā)送端實時傳輸子系統(tǒng)之間主要采用光纖鏈路通 信，光纖鏈路故障狀態(tài)下采用備用的衛(wèi)星鏈路通信。鏈路正常狀態(tài)下，各發(fā)送端 按照時間表實時向接收端傳輸接收到的衛(wèi)星數(shù)據(jù)；鏈路異常狀態(tài)下，各發(fā)送端采 用文件傳輸?shù)男问较蚪邮斩藗鬏斝l(wèi)星數(shù)據(jù)。數(shù)據(jù)傳輸過程中，需要傳輸?shù)倪€有通 信中的請求、應答、命令等信息。 每個實時傳輸子系統(tǒng)需要與本地的通信設備監(jiān)控子系統(tǒng)通信。實時傳輸子系 統(tǒng)將傳輸狀態(tài)、告警信息等傳遞給通信設備監(jiān)控子系統(tǒng)并加以顯示。 1 、功能性需求 1 ) 傳輸任務調(diào)度功能 由傳輸任務調(diào)度模塊負責整個通信行為的監(jiān)控與調(diào)度，用來守護、管理、調(diào) 度、監(jiān)控整個子系統(tǒng)。 2 ) 運控重傳管理功能 接收端地面站需要接收來自運控分系統(tǒng)的重傳命令；根據(jù)命令將傳輸指令分 發(fā)到其他地面站；實時傳輸子系統(tǒng)需要根據(jù)收到的命令完成數(shù)據(jù)傳輸工作。 3 ) 通信傳輸鏈路手動選擇功能 軟件對用戶提供光纖通信鏈路傳輸方式和v s a t 衛(wèi)星專用信道傳輸方式選擇 功能。 用戶可通過人機交互界面中的菜單選擇或者腳本配置的方式，根據(jù)實際需要 切換傳輸信道。 系統(tǒng)能夠根據(jù)用戶的實際選擇，對傳輸文件進行相應的處理。 4 ) 通信傳輸鏈路自動配置功能 實時傳輸子系統(tǒng)在用戶未選擇手動配置或者腳本配置傳輸方式的前提下，自 動選擇一個默認的傳輸方式。此默認傳輸方式可以由用戶手動配置。如果用戶未 配置，則默認為光纖傳輸方式。 5 ) 通信傳輸鏈路自動切換功能 實時傳輸子系統(tǒng)能夠根據(jù)當前鏈路的實際狀況自動選擇切換傳輸方式。 如果當前光纖鏈路出現(xiàn)故障或者收發(fā)超時，該子系統(tǒng)應當及時切換到衛(wèi)星鏈 路傳輸，并且向監(jiān)視子系統(tǒng)和運控分系統(tǒng)報警。 如果當前光纖鏈路故障恢復，該子系統(tǒng)應當在傳輸完成當前數(shù)據(jù)之后，及時 切換回光纖鏈路進行下一數(shù)據(jù)的傳輸，并且向監(jiān)視子系統(tǒng)和運控分系統(tǒng)報告鏈路 恢復狀態(tài)。 北京j | i | j l u 人學順i ：學位論義 6 ) 實時遙感數(shù)據(jù)傳輸功能 實時傳輸子系統(tǒng)需要將每個地面站接收到的實時遙感數(shù)據(jù)在第一時問安全、 準確的傳輸?shù)阶罱K接收端地面站。 子系統(tǒng)需根據(jù)實際鏈路情況設置緩沖池，保證數(shù)據(jù)的傳輸效率和準確性。 7 ) 實時數(shù)據(jù)強占式傳輸功能 因為每個地面站都有多顆衛(wèi)星數(shù)據(jù)的接收，當出現(xiàn)接收數(shù)據(jù)沖突的時候，應 該根據(jù)用戶的預先配置，高優(yōu)先級的接收數(shù)據(jù)可以搶占低優(yōu)先級的接收數(shù)據(jù)，并 優(yōu)先傳輸。 需要向運控分系統(tǒng)報告本系統(tǒng)的搶占情況。 8 ) 實時數(shù)據(jù)靜態(tài)備份功能 該子系統(tǒng)在實時傳輸衛(wèi)星遙感數(shù)據(jù)的同時，應將數(shù)據(jù)備份到磁盤，將數(shù)據(jù)靜 態(tài)化，以防數(shù)據(jù)丟失；在發(fā)生搶占后，高優(yōu)先級的數(shù)據(jù)優(yōu)先傳送，低優(yōu)先級的數(shù) 據(jù)需要保留到磁盤，待信道空閑后，再次發(fā)送到地面站。 9 ) 實時傳輸和靜態(tài)數(shù)據(jù)保存自動切換功能 能夠根據(jù)鏈路的實際狀態(tài)，實時接收并同步轉(zhuǎn)發(fā)遙感數(shù)據(jù)。 根據(jù)鏈路類型和狀態(tài)的不同，系統(tǒng)將做出如下工作： ( 1 ) 如果當前采用光纖鏈路，且鏈路狀態(tài)暢通，則系統(tǒng)將實時接收并同步 轉(zhuǎn)發(fā)遙感數(shù)據(jù)； ( 2 ) 如果當前采用光纖鏈路，但鏈路狀態(tài)出現(xiàn)問題，無法連通，則將數(shù)據(jù) 存儲為文件，并且換到衛(wèi)星鏈路傳輸，轉(zhuǎn)發(fā)文件； ( 3 ) 如果當前采用衛(wèi)星鏈路，且鏈路狀態(tài)暢通，則系統(tǒng)實時接收數(shù)據(jù)，并 保存為文件，轉(zhuǎn)發(fā)文件； ( 4 ) 如果當前采用衛(wèi)星鏈路，但鏈路狀態(tài)出現(xiàn)問題，無法連通，則將數(shù)據(jù) 存儲為文件。 1 0 ) 數(shù)據(jù)傳輸狀態(tài)報告功能 實時傳輸子系統(tǒng)能夠向運控分系統(tǒng)報告當前數(shù)據(jù)的傳輸狀態(tài)，并在出現(xiàn)異常 時提交報警信息，便于監(jiān)控人員進行處理。 1 1 ) 數(shù)據(jù)傳輸狀態(tài)監(jiān)視功能 通過人機交互界面可以查看實時傳輸子系統(tǒng)當前數(shù)據(jù)的傳輸狀態(tài)和任務調(diào) 度等。 1 2 ) 斷點續(xù)傳功能 實時傳輸子系統(tǒng)能夠在上次數(shù)據(jù)傳輸失敗的地方繼續(xù)傳輸剩余的原始數(shù)據(jù)， 以減少重傳的工作量，提高傳輸效率。 1 3 ) 工作日志功能 1 4 北京郵i u 人學頌i j 學位論文 能夠及時準確的記錄數(shù)據(jù)傳輸任務及軟件工作狀態(tài)。 1 4 ) 數(shù)據(jù)壓縮和解壓縮功能 發(fā)送方根據(jù)系統(tǒng)配置要求采用相應的壓縮算法對原始數(shù)據(jù)進行實時無損壓 縮，以降低對傳輸帶寬的要求； 接收方能對接收到的壓縮碼流進行實時解壓縮，恢復原有碼流。 1 5 ) 多碼流調(diào)度與流控功能 根據(jù)優(yōu)先級分配數(shù)據(jù)傳輸帶寬。 1 6 ) 軟件配置 能夠方便快捷地配置軟件運行環(huán)境和參數(shù)，運用交互式、圖形化的方式幫助 管理員配置各種信息。 能夠?qū)Σ煌瑪?shù)據(jù)來源的數(shù)據(jù)碼流進行調(diào)度與流量控制。 2 、質(zhì)量特性 1 ) 系統(tǒng)能夠高穩(wěn)定、高可靠地運行，系統(tǒng)可靠性達到9 9 9 。系統(tǒng)能自動檢 測并重置僵死進程，保證系統(tǒng)的穩(wěn)定和健壯。 2 ) 當采用衛(wèi)星信道傳輸方式時，為了充分利用衛(wèi)星信道帶寬，要求兩個發(fā) 送端地面站至接收端的文件傳輸軟件能夠適當提高等效傳輸帶寬，信道利用率達 n 8 5 以上。 一3 ) 當采用光纖信道傳輸方式時，要求達到8 5 以上的信道利用率。 4 ) 實時傳輸時，提供q o s 服務，保證數(shù)據(jù)不因鏈路不穩(wěn)定而丟失數(shù)據(jù)或出 錯。 5 ) 人機交互界面響應時間不超過3 秒。 3 、可靠性要求 通信分系統(tǒng)采用可靠、成熟的技術開發(fā)，以保證軟件系統(tǒng)具有一定容錯性、 易恢復性。 軟件故障：在系統(tǒng)出現(xiàn)故障后立即退出重啟。 硬件故障：保存當前狀態(tài)信息。 4 、易用性要求 通信分系統(tǒng)有監(jiān)控和人機交互畫面，軟件設計中盡量采用面向?qū)ο蠹夹g，以 直觀、美觀和方便易學的界面提供給操作員和管理員。每個畫面要求有聯(lián)機提示 和聯(lián)機幫助。 5 、維護性要求 通信分系統(tǒng)按軍標軟件工程設計，要求最終軟件系統(tǒng)始終與文檔保持一致。 文檔包括中文文檔和硬拷貝兩類，要求同時更新。 北京郵f 【i 人學碩j ：學位論文 第四章實時傳輸子系統(tǒng)的設計與實現(xiàn) 4 1 實時傳輸子系統(tǒng)模型設計 4 1 1 采用主從模式 按照x x x x 衛(wèi)星實時傳輸子系統(tǒng)的需求，只允許接收端向發(fā)送端下達命令消 息，反向的命令發(fā)送是不可以的，發(fā)送端只可以向接收端發(fā)送衛(wèi)星數(shù)據(jù)消息。在 這種情況下，只能采用主從模式，才符合要求。