注銷

          注銷

            BlogJava :: 首頁 :: 新隨筆 :: 聯系 :: 聚合  :: 管理 ::
            112 隨筆 :: 7 文章 :: 18 評論 :: 0 Trackbacks

          短消息網關通信模塊的設計與實現

          鄧麗華 1 ,黃華 1 ,張靖宇 2

          1. 四川大學電氣信息學院 ? ?2. 時力永聯科技有限公司)

          在闡述短消息網關結構的基礎上,提出了短消息網關通信模塊的設計思想,并給出了該通信模塊的具體實現。

          關鍵詞: 短消息 ; 短消息網關 ; 通信

          1??????? 前言

          隨著通信技術的發展,無線互聯網短消息業務正在為用戶提供越來越多的服務。人們不僅可以通過手機點播定制新聞、股票信息、天氣預報,還可以下載鈴聲、圖片等。無論需要什么樣的信息,我們都可以隨時隨地地通過手機接入互聯網絡,享受各種服務。電信運營商要實現這些增值業務,就必須支持網間的互聯互通。

          目前實現網間互聯互通的方式有四種,包括:通過移動關口局互聯互通;通過信令轉接點互聯互通;通過短消息網關互聯互通;通過第三方運營商系統互聯互通。前兩種方式不易設置計費點和引出計費話單,因此不利于網間結算;最后一種方式,雖然能夠保證計費點和結算點的統一,但是易受到地域條件的限制 而通過短消息網關實現互聯互通,無須對 現網運行的設備進行大面積的數據改動和升級改造,能夠 合理的設置計費點,保證計費的準確性,實現業務鑒權和業務過濾的功能,保證網絡的安全,也能夠通過對業務流量的監視和控制,防止網絡風暴的發生,這種互聯方式具有其他三種方式不可比擬的優點。目前,大部分短消息業務的互聯互通都是使用短消息網關來實現。

          2??????? 短消息網關結構

          短消息網關( ISMG )是處于短消息中心( SMSC )和業務提供商( SP )之間的設備,它為這兩個實體的數據交換提供安全、快捷的通道。網關與短消息中心之間使用 SMPP 協議( Short Message Peer to Peer, 短消息點對點協議) , SP 之間使用 CMPP 協議( China Mobile Peer to Peer, 中國移動點對點協議),因此短消息網關需要完成協議的轉換、計費、路由、安全和網絡管理等功能。其結構圖如圖 1 所示。

          SMPP

          CMPP

          ?

          ?

          ?

          ?

          ?

          ?

          ?

          ?

          ? 短消息網關( ISMG

          ?

          SMSC

          ? SMPP 通信代理系統

          短消息網關處理系統

          SP

          ? CMPP 通信代理系統

          短信網關計費系統

          業務管理系統

          防火墻系統

          具體說來,圖 1 SMPP 通信代理系統主要實現網關和 GSM 網中短消息中心( SMSC )的連接,確保準確接收和發送數據,實現高效、可靠的數據傳輸。為了達到規范要求的不超過 0.001% 的數據丟包率, SMPP 通信代理需要支持流量控制。 CMPP 通信代理系統主要是實現和 SP 服務提供商的連接,與 SMPP 通信代理系統不同的是,由于協議的影響, CMPP 通信代理是服務器端,需等待 SP 的連接,而 SMPP 通信代理是客戶端,需要主動連接 SMSC 。短消息網關處理系統是網關中最復雜的處理進程,它完成的任務包括:向 GNS( 匯接網關 ) 查詢路由,維護路由表,進行協議轉換和數據分發。防火墻系統主要為網關系統提供安全保障,它包括 IP 包過濾和身份驗證。短信網關計費系統主要形成各種計費話單,為計費提供依據。業務管理系統主要完成對業務進行統計報告,生成報表,為運營者對用戶數據的添加、修改、刪除以及對網關系統的監控、查詢、操作和維護提供接口和界面。

          ?

          3??????? 短消息網關通信模塊的設計與實現

          短消息網關通信模塊是整個短消息網關的基礎。無論是計費、統計,還是超時重傳,高質量的通信構架是必不可少的保障。這個通信構架不僅要完成基本的收發消息的功能,而且還要有好的結構以支撐各種業務需求,保證良好的擴展性。

          3.1.??????? 短消息網關通信模塊的設計

          在設計短消息網關通信模塊時,我們考慮了以下幾點:

          第一,由于短消息網關功能繁多,如果把通信和具體業務合在一起開發,容易顧此失彼。可能會因為開始的考慮不周全,造成在增加某項新業務時不得不修改通信底層和原來的業務代碼,導致重復開發。所以我們采用通信代理的方式把通信和具體業務分開,在增加新業務時,就只需少量修改通信代理的設置,而且不必再改動原來的業務代碼了。

          第二,通信代理需要同時偵聽多個端口,我們選用多路復用 I/O 這種方式。雖然多線程能夠通過并行計算和共享內存提高代碼效率和資源利用率,但在短消息網關中,處理的數據量大,多線程方式的并行處理會造成一些消息的邏輯混亂,資源共享也會增加代碼的復雜度。而多路復用使用簡單,邏輯清晰明了,不易發生錯誤,也不會出現因資源共享帶來同步和互斥問題。因此使用多路復用 I/O 是比較合理的。

          第三,業務處理模塊與通信代理之間可以使用隊列進行通信,對隊列的管理和參數的設置(例如對同一隊列操作的互斥,以及隊列個數的設置等)都使用專門的隊列內核程序統一調度并封裝成函數接口,以方便業務處理模塊對隊列的使用。另外,通過隊列通信,也可以為今后增加的業務提供良好的擴展性。

          第四,為了達到99.999%的不丟包率,通信代理需要使用流量控制機制以保證網關內部不丟包。這是因為無論隊列設置有多大,如果出現消息只發不收的情況,都會造成隊列溢出而丟包。因此,為每個隊列中緩存的消息做記錄,當某個時刻隊列消息的數量達到規定限度,隊列就不再收包,以保證到達網關的消息不會丟失。

          3.2.??????? 短消息網關通信模塊的實現

          基于以上設計思路,我們實現的短消息通信模塊包括四個父進程: CMPP 通信代理 (cmpp_server) SMPP 通信代理 (smpp_server) 、消息分發處理 server(package_server) 和前轉消息處理 server(route_server) 。它們之間通過 6 個消息隊列相互通信。具體的軟件結構如圖 2 所示。

          Cmpp_server 主要為 SP 和網關之間建立一條高質量的傳輸通道。它同時偵聽與它相連的多個 socket ,通過隊列接口函數 mqm_send( ) 把接收到的 CMPP 格式的消息送入隊列 2 中。同時,它也要通過函數 mqm_recv( ) 不停的從隊列 1 中獲得消息,并把它轉發到相應的目的 SP cmpp_server 不需判斷收到的消息類型,只負責通信,因此稱通信代理。

          Smpp_server cmpp_server 基本一致,唯一不同的只有一點: SMPP 協議規定 smpp_server 是客戶端,需要主動發起建立連接的請求;而 CMPP 協議規定 cmpp_server 是服務器端,需等待對方連接。

          Package_server 是短消息網關的核心,所有的消息都要經過它,包括協議轉換,超時重傳,計費,路由,都需要在 package_server 中完成。 package_server 同時監聽 2 4 6 三個隊列,根據不同的消息頭來判斷這個消息的下一個目的地。路由表也需要在 package_server 中維護,以便 package_server 能得到路由信息,轉發消息。如果路由表中找不到相關的信息, package_server 就要把該消息轉發給 route_server ,由 route_server 從匯接網關處獲得路由信息后發送該消息。

          Route_server 主要處理需要轉發到其他網關的消息。當 package_server 發現消息的目的地不是本地網關所連的 SP SMSC ,那么它就會把消息轉發給 route_server 處理。 Route_server 接到消息后與匯接網關通信,請求目的地的網關地址,然后與目的網關建立 socket 連接,交付該消息并記錄前轉話單。

          ?????? 在整個通信模塊中,所有的 server 都使用隊列接口函數 mqm_init( ) 初始化消息隊列并復接在隊列上。收發數據使用 mqm_send( ) mqm_recv( ) 函數完成。存儲消息采用固定的數據結構,其結構如下:

          struct mqm_connection {

          unsigned int??????????? package_server_seqnum; // 由網關自行產生。若消息從隊列 4 中來,該元素將是轉化后的 CMPP 協議格式的消息序列號;若消息從隊列 2 中來,該元素將是轉化后的 SMPP 協議格式的消息序列號。

          ?????? short?????? ????????????? mqm_sockfd; // 接收該消息的 socket;

          ?????? short?????? ????????????? mqm_seqnum; // 收到的消息序列號;

          ?????? time_t???? ????????????? mqm_timeout;// 收到該消息的時間;

          ?????? int?????????? ????????????? total_length; // 該消息的長度;

          ?????? char????????????? ??? mqm_buf[MAX_PACKET_SIZE]; // 該消息的內容;

          char????????????????????? converted_buf[MAX_PACKET_SIZE]; // 轉換協議后的消息內容;

          };

          現以 MO 請求業務為例,描述通信模塊的工作流程。

          SMSC SMPP 格式的 DELIVER_SM 消息發出訂閱某個 SP 的言語傳情短消息,經由 smpp_server 收到,從隊列4中轉發給 package_server Package_server 收到 MO 請求后回送給 SP 一個 SMPP 格式的 DELIVER_SM_REP 應答消息,并用 mqm_connection 結構體存儲這條 MO 消息的各個信息。 之后, package_server 就把該消息轉換成 CMPP 協議的 CMPP_Deliver 消息,并通過隊列1送到 cmpp_server 中,轉發給目的 SP SP 在接收到這個消息后,會產生一個 CMPP 格式 CMPP-_Deliver_Rep 的應答消息返回給網關。當 package_server 收到了應答信號,也需要用 mqm_connection 結構體存儲。這時,一條 MO 短消息轉發成功, package_server 記錄 SMO 話單。

          下面給出在Linux7.2版本的操作系統下,用C語言實現的package_server的主要代碼:

          main ()

          {

          ??????? ?????? mqm_init( ); // 初始化隊列;

          ?????????????? ……

          ?????????????? pipe( ); // 建立管道 ;

          ?????????????? if (( child_pid = fork( ) ) ==0)

          ?????????????? {

          ????????????????????? // 通過管道通知 2 隊列有數 ;

          ????????????????????? while(1){

          ?????????????? ???????????????????? get_result_msg_info(REQUEST_2,pipfd2[1]);

          ??????? ??????????????????????????? }

          ?????????????? }

          ?????????????? ……

          ?????????????? // 建立監聽描述符集 ;

          ?????????????? FD_ZERO ( &monit);

          ?????????????? FD_SET ( )_;

          ?????????????? ……

          ?????????????? // 處理隊列中來的數據

          ?????????????? while(1)

          ?????????????? {

          ????????????????????? ?select ( ); // 監聽 2,4,6 隊列 ;

          ????????????????????? if ( FD_ISSET(queue2,&read_monit ))? // 如果 2 隊列有數 ;

          ????????????????????? {

          ??????????????????????????????????? handle_queue2_in( );// 處理 2 隊列來的數據 ;

          ????????????????????? }

          ????????????????????? ……

          ?????????????? }//end while;

          } //end main

          4???????? 結束語

          短消息網關是 無線互聯網短消息業務中最為關鍵的一個設備, 它為手機用戶和互聯網的信息資源架起了一座橋梁。本文中短消息網關的通信模塊設計周全,結構合理,為計費、路由、超時重傳等模塊提供了良好的擴展性。經實驗室測試,在奔 2 處理器, 64 兆內存的機器上,收發包速率為每秒 5000 條,不丟包率達到 100% ,是一個穩定的系統。

          參考文獻

          [1] 短消息網關設備規范 (V1.2). 中國移動通信集團公司, 2001.

          [2] 中國移動通信短消息網關測試規范( V1.2 . 中國移動通信公司, 2001.

          [3] 中國移動通信信息資源站實體與互聯網短消息網關接口協議( V1.3 . 中國移動通信集團公司, 2001.

          [4] Short Message Peer to Peer Protocol Specification v3.4 .SMPP Developers Forum 1999.

          [5] W.Richard Stevens.UNIX 網絡編程 . 施振川,周利民,孫宏暉等譯 . 清華大學出版社, 1999.

          ?



          Trackback: http://tb.blog.csdn.net/TrackBack.aspx?PostId=268295

          posted on 2006-10-19 10:36 注銷..... 閱讀(364) 評論(0)  編輯  收藏

          只有注冊用戶登錄后才能發表評論。


          網站導航:
           
          主站蜘蛛池模板: 永顺县| 利川市| 北宁市| 金门县| 公主岭市| 察雅县| 玛沁县| 广灵县| 卓资县| 鱼台县| 青岛市| 宜黄县| 永福县| 衢州市| 莱西市| 盐山县| 玉溪市| 福鼎市| 榆中县| 偃师市| 张家川| 惠州市| 曲麻莱县| 虹口区| 西林县| 阿克苏市| 建湖县| 高州市| 射洪县| 黑河市| 汉阴县| 滦平县| 宜兴市| 柳河县| 岱山县| 金湖县| 崇礼县| 贵德县| 万源市| 广饶县| 东光县|