３Ｇ移動數(shù)據(jù)業(yè)務(wù)平臺中短消息增值業(yè)務(wù)的開發(fā)與研究

摘要：針對移動數(shù)據(jù)業(yè)務(wù)發(fā)展和運營過程中出現(xiàn)的問題，給出了一種在3G移動數(shù)據(jù)業(yè)務(wù)平臺(MDSP)上開發(fā)短信增值業(yè)務(wù)的方法和技術(shù)。通過增加短信二次確認流程、黑白名單等功能，解決了短信業(yè)務(wù)所存在的兩個問題；應(yīng)用Session緩沖機制、多線程技術(shù)等提高了系統(tǒng)性能，使流程的設(shè)計方法得以改進，在具體的項目開發(fā)中起到了很好的效果，從而提高了管理SP的能力，使短信增值業(yè)務(wù)由對SP的弱管理模式轉(zhuǎn)變到對SP的強管理模式（杜絕和防止了SP欺詐用戶的行為），極大地維護了運營商的品牌形象，維護了用戶利益，規(guī)范了短信增值市場。

關(guān)鍵詞：移動數(shù)據(jù)業(yè)務(wù)平臺;短消息增值業(yè)務(wù);Session緩沖機制;多線程

中圖法分類號：TP39309文獻標識碼：A

文章編號：1001－3695(2006)09－0175－04

1引言

隨著移動通信的強勁發(fā)展，3G移動通信時代即將來臨。簡單地講，3G是指將無線通信與國際互聯(lián)網(wǎng)等多媒體通信結(jié)合的新一代移動通信系統(tǒng)，它能夠處理文本、圖像、音樂、視頻流等多種多媒體形式。為了能夠支持這種服務(wù)，無線網(wǎng)絡(luò)必須能夠支持不同的數(shù)據(jù)傳輸速率，在室內(nèi)、室外和行車的環(huán)境中能夠分別支持至少2Mbps，384kbps以及144kbps的傳輸速率［1］。3G網(wǎng)絡(luò)能力的提高，為高速高帶寬數(shù)據(jù)業(yè)務(wù)提供了底層承載，同時SP/CP（服務(wù)提供商/內(nèi)容提供商）的積極廣泛參與增值數(shù)據(jù)業(yè)務(wù)運營，使得新的、細化的、專業(yè)化的、共同合作的3G移動產(chǎn)業(yè)價值鏈逐步形成。

2G的GSM系統(tǒng)、2.5G的GPRS系統(tǒng)的移動夢網(wǎng)業(yè)務(wù)，由于SP/CP逐步參與其以短消息為主要特征和代表的數(shù)據(jù)業(yè)務(wù)運營過程，隨著參與的數(shù)量、規(guī)模和方式的變化，迫切需要加強SP的監(jiān)管和改革運營模式。主要表現(xiàn)為以下迫切需要解決的問題：

(1)開放業(yè)務(wù)模式下的有效監(jiān)管難題。短信業(yè)務(wù)的成功確立了開放的業(yè)務(wù)提供模式，即業(yè)務(wù)由CP/SP提供，運營商提供基礎(chǔ)網(wǎng)絡(luò)平臺與運營支撐平臺。SP計費、運營商代收費的模式被普遍采用，由此也帶來了很大的弊端。由于現(xiàn)有網(wǎng)絡(luò)結(jié)構(gòu)無法對SP業(yè)務(wù)實施的環(huán)節(jié)進行有效控制，SP強行給用戶莫名其妙地、不經(jīng)用戶同意就給用戶訂閱上某種服務(wù)，SP做假賬、亂收費、價格欺詐現(xiàn)象屢屢發(fā)生，用戶投訴不斷，嚴重影響了運營商的品牌形象(稱作對SP的弱管理）。而且，由于SP隊伍發(fā)展迅速，運營商現(xiàn)有的管理模式已很難滿足開放環(huán)境的要求，工作量大、效率低、管理成本不斷攀升。開放的業(yè)務(wù)模式迫切需要一套新的業(yè)務(wù)管理支撐平臺，可以提供快速便捷的業(yè)務(wù)發(fā)布系統(tǒng)。統(tǒng)一的用戶管理、業(yè)務(wù)管理，個性化的業(yè)務(wù)定制與呈現(xiàn)，嚴格的訪問控制，切實有效的合作伙伴管理等功能［2］。

(2)垃圾短信問題。有的SP發(fā)送垃圾廣告等短信騷擾用戶，給用戶帶來痛苦和麻煩，還有的非法組織發(fā)送對輿論造成壞影響的短信，給社會和個人帶來了負面影響。引入移動數(shù)據(jù)業(yè)務(wù)平臺后，通過提供黑白名單功能，用戶可以把這些SP或者非法組織列入黑名單中，系統(tǒng)也可以把其列入黑名單中，還可以通過提供短信內(nèi)容關(guān)鍵字過濾以禁止這些短信Push下去。

業(yè)界為了解決以上問題，提出了在運營商的核心數(shù)據(jù)網(wǎng)絡(luò)中引入移動數(shù)據(jù)業(yè)務(wù)平臺（MobileDataServicePlatform，MDSP）。這樣，短信增值業(yè)務(wù)的流程就要增加與移動數(shù)據(jù)業(yè)務(wù)平臺交互（鑒權(quán)、同步、更新等）這些環(huán)節(jié)，還有短信訂購流程中增加二次確認環(huán)節(jié)等。通過業(yè)務(wù)流程的改變就可以實現(xiàn)對SP的強管理，但盡量使得SP的改動很小，這樣可以保護SP的投資和運營（稱作對SP的零改動）。

如何在3G移動數(shù)據(jù)業(yè)務(wù)平臺上，在其通信協(xié)議實現(xiàn)的基礎(chǔ)上，設(shè)計這些短信增值業(yè)務(wù)是本文的研究重點。

2移動數(shù)據(jù)業(yè)務(wù)平臺基本原理

3G移動數(shù)據(jù)業(yè)務(wù)平臺主要可分為三大部件來實現(xiàn)和研究：①MDMC（MobileDataManagementCenter），主要展示和提供給運營商及SP發(fā)布和審批業(yè)務(wù)，SP的申請注冊、審批通過成為正式商用SP和SP注銷等都可以通過它進行。這一部分由于要展示給運營商和SP操作，對用戶界面要求比較友好，故用JSP技術(shù)來實現(xiàn)，可以采用分層的方法抽象。②Portal，展示給用戶和運營商發(fā)布業(yè)務(wù)與用戶瀏覽業(yè)務(wù)信息（業(yè)務(wù)名稱、特點、費率等）、定制、退定業(yè)務(wù)的門戶網(wǎng)站。該部分用JSP技術(shù)實現(xiàn)。③最重要的部分是MDCC(MobileDataControlCenter)，這部分主要完成業(yè)務(wù)的控制（鑒權(quán)（包括用戶鑒權(quán)、SP和業(yè)務(wù)鑒權(quán)）、計費），完成外部實體TCP的長連接接入、協(xié)議適配、消息轉(zhuǎn)發(fā)。

3G移動數(shù)據(jù)業(yè)務(wù)平臺是與網(wǎng)關(guān)連接的數(shù)據(jù)網(wǎng)絡(luò)核心部件，其原理是：以短信業(yè)務(wù)為例，當用戶向SP發(fā)起MO短消息，或SP向用戶發(fā)送MT短消息，短信網(wǎng)關(guān)向MDSP發(fā)起鑒權(quán)批價請求，MDSP根據(jù)數(shù)據(jù)庫中的數(shù)據(jù)對MO/MT進行鑒權(quán)和批價，然后給網(wǎng)關(guān)返回鑒權(quán)批價響應(yīng)，網(wǎng)關(guān)據(jù)此決定下一步操作，以實現(xiàn)對SP、業(yè)務(wù)、業(yè)務(wù)費率、用戶信息、訂購關(guān)系進行管理。

引入該平臺后，SMS(ShortMessageService)短消息業(yè)務(wù)的典型組網(wǎng)圖如圖1所示。

3G移動數(shù)據(jù)業(yè)務(wù)平臺與網(wǎng)關(guān)的連接是建立在TCP/IP連接基礎(chǔ)上的，應(yīng)用層使用SMAP（中國移動，ShortMessageApplicationProtocol）、SPAP（中國聯(lián)通，ServiceProviderAccessProtocol）、CMPP［3］（中國移動，ChinaMobilePeertoPeer）、SGIP［4］（中國聯(lián)通，ShortMessageGatewayInterfaceProtocol）、SMGP［5］（中國電信，ShortMessageGatewayProtocol）、CNGP［6］（中國網(wǎng)通，ChinaNetworkGatewayProtocol）進行通信的。這些協(xié)議需要MDSP平臺支持，是MDSP上業(yè)務(wù)的底層承載。MDSP通過解析這些協(xié)議的消息字段值來觸發(fā)和開展業(yè)務(wù)，當有業(yè)務(wù)產(chǎn)生時，MDSP建立對應(yīng)Session會話來保存該消息字段的關(guān)鍵字段值。這樣做的目的是提高性能，Session建立后，根據(jù)業(yè)務(wù)流程（業(yè)務(wù)邏輯）來進行對數(shù)據(jù)庫訪問和操作，然后把結(jié)果返回給網(wǎng)關(guān)。這樣實現(xiàn)一次業(yè)務(wù)的完成，如圖2所示（此即為一個簡單的業(yè)務(wù)流程圖）。

3MDSP中短消息增值業(yè)務(wù)流程的開發(fā)

3．1業(yè)務(wù)流程（改進的業(yè)務(wù)流程）開發(fā)方法

移動數(shù)據(jù)業(yè)務(wù)平臺上可承載的業(yè)務(wù)可以不斷地擴充，提供的接口靈活，可以很方便地擴展新業(yè)務(wù)。因其體系結(jié)構(gòu)清晰合理，底層承載通信模塊FEP如果業(yè)務(wù)使用的通信協(xié)議不改變，就不需要改變協(xié)議棧通信模塊，而只需要在具體的處理業(yè)務(wù)流程的UIDB(UniversalInterfaceDataBase)模塊中進行添加或修改業(yè)務(wù)流程函數(shù)，以及在負責對業(yè)務(wù)進行費率鑒權(quán)和進行計費的Charge模塊中進行修改或添加有關(guān)函數(shù)。

下面以短消息增值業(yè)務(wù)的主要業(yè)務(wù)：定制類業(yè)務(wù)和點播類業(yè)務(wù)為例來介紹其流程在MDSP中的具體開發(fā)和實現(xiàn)。圖3為改進的增加了二次確認流程的短消息定制類業(yè)務(wù)流程圖。

UIDB模塊是MDCC部件中非常重要的模塊，主要由服務(wù)器端進程和客戶端進程來完成具體的業(yè)務(wù)流程，負責對數(shù)據(jù)庫中業(yè)務(wù)、用戶、SP的數(shù)據(jù)進行訪問和管理。UIDB模塊分為UClient進程端和USrv進程端。如系統(tǒng)平臺收到AuthPriceReq請求，并把該請求消息送到UDIB的UClient端，我們就在UClient進程端建立TIsmgAuthPriceReqSession類型的對象。TIsmg－AuthPriceReqSession類是該進程中要用到的主要類，其數(shù)據(jù)成員主要有srcAccessNo，srcAddress，feeUserType，destUserType，feeMsisdn，destMsisdn，result，operType，subResult，F(xiàn)eeType，msgFmt，srcFeatureStr，specialMOType，m_smsType，gwMsgId，accessNoLen，moType，addOperStr，pkTotal，pkNumberd，TSessionState（標志TIsmgAuthPriceReqSession的狀態(tài)），m_clientSessionId等字段；成員函數(shù)主要有TIsmgAuthPriceReqSession()，Init(TCodecode)，event(TCodecode)，spAuth()，ServiceAuth()，Init_MO，Init_MT()，ToIsmgSMS()，ToChargeSMS()，ParseSMSContent()等。由UClient進程main()主函數(shù)調(diào)用構(gòu)造函數(shù)構(gòu)造TIsmgAuthPriceReqSession型對象，如果構(gòu)造成功，則調(diào)用Init（）函數(shù)進行流程判斷，根據(jù)serviceType字段的值來判斷執(zhí)行Init_MO()流程還是Init_MT()流程。如果進入的是Init_MO()流程，則在此函數(shù)中調(diào)用spAuth()函數(shù)進行SP鑒權(quán)，如果鑒權(quán)成功，則繼續(xù)調(diào)用ServiceAuth()函數(shù)進行業(yè)務(wù)鑒權(quán)；如果spAuth()函數(shù)鑒權(quán)失敗，返回False，則Init_MO()函數(shù)做后續(xù)處理，置AuthPriceRsp消息的Result字段為對應(yīng)返回碼，并且把此消息編碼打包通過協(xié)議棧（只需發(fā)往協(xié)議棧調(diào)用接口）發(fā)往ISMG網(wǎng)關(guān)。如果ServiceAuth()函數(shù)返回失敗，則AuthPriceRsp消息的Result字段填寫對應(yīng)返回碼，編碼打包發(fā)往網(wǎng)關(guān)，如果經(jīng)過spAuth()和ServiceAuth()流程函數(shù)后，此兩函數(shù)都返回True，則說明SP和業(yè)務(wù)都鑒權(quán)成功。在Init_MO()函數(shù)里繼續(xù)進行后續(xù)處理，填寫AuthPriceRsp消息的Result字段為0（表示成功），并構(gòu)造、編碼、發(fā)送到網(wǎng)關(guān)。此即完成了流程中AuthPriceReq和AuthPriceRsp消息對中MDSP的鑒權(quán)、批價流程，然后還要把這個訂購關(guān)系寫入數(shù)據(jù)庫表tmpSubscribe－Record(此表用來保存臨時訂購關(guān)系)，最后此函數(shù)返回到main（）函數(shù)中。

對于MT業(yè)務(wù)，我們調(diào)用Init_MT()函數(shù)，通過SPID和ServiceID去進行SP鑒權(quán)、業(yè)務(wù)鑒權(quán)（通過調(diào)用spAuth()函數(shù)和ServiceAuth()函數(shù)完成），如果是訂購類業(yè)務(wù)，我們到保存訂購關(guān)系的表SubscribeRecord中去查詢是否存在此用戶的訂購關(guān)系，如果存在才能繼續(xù)下發(fā)此業(yè)務(wù)，通過返回消息AuthPriceRsp字段中的Result字段告知網(wǎng)關(guān)。如果沒有，則返回False，被拒絕下發(fā)。如果業(yè)務(wù)類型是點播類業(yè)務(wù)，則到temp－OrderRecord表中去查詢，看是否有該用戶的點播關(guān)系存在，如果存在，返回消息(AuthPriceRsp)的Result字段賦值為0，表示可以下發(fā)下去。同時把此點播關(guān)系表tempOrderRecord中的該用戶點播關(guān)系刪去，并以消息的形式通知Charge模塊進行扣費處理并寫話單。此即完成了一個點播類業(yè)務(wù)的SP下發(fā)(MT)。我們在其中進行了SP鑒權(quán)和業(yè)務(wù)（業(yè)務(wù)類型，費率）鑒權(quán)，這樣就從流程上禁止了SP非法進行MTPush業(yè)務(wù)，也禁止了SP自行或強制給用戶訂購業(yè)務(wù)，做到了讓用戶透明使用業(yè)務(wù)（業(yè)務(wù)展示在Portal通過網(wǎng)頁或者WAP終端），業(yè)務(wù)費率事先公布在Portal上，批價、扣費、計費、生成話單由我們平臺MDCC的Charge模塊來完成。此舉改變了現(xiàn)在由SP來計費、運營商代收費的運營模式，徹底杜絕了SP亂收費的可能，為短信增值業(yè)務(wù)的發(fā)展提供了透明、可控制、可管理的環(huán)境和方式。

在UClient進程的main()主函數(shù)中會調(diào)用一個Router（），此函數(shù)主要是循環(huán)檢測是否有消息發(fā)來，如果檢測到，則在main()函數(shù)里調(diào)用具體處理此消息的業(yè)務(wù)控制函數(shù)。如果匹配到AuthPriceCfmReq消息，則首先根據(jù)msgid找到TIsmgAuthPriceReqSession中保存的信息（關(guān)鍵是SpCode和ServiceID），還要調(diào)用ParseSMSContent()函數(shù)把短信內(nèi)容解析為系統(tǒng)所能識別的編碼形式，如果解析出的是“Y”或“y”，則在保存臨時訂購關(guān)系的數(shù)據(jù)庫表tmpSubscribeRecord中去查詢臨時訂購關(guān)系是否存在（根據(jù)msisdn（用戶號碼）、SpCode和ServiceID去查詢）。如果查到，通過給TIsmgAuthPriceCnfmReqSession的一個字段變量如queryflag賦值來標記查到，在查完相關(guān)控制流程函數(shù)（收取通道費、預(yù)收取信息費并寫入話單記錄中）后把這個正式的訂購關(guān)系寫入SubscribeRecord表中（此表記錄正式訂購關(guān)系），然后我們給網(wǎng)關(guān)回響應(yīng)消息AuthPriceCnfmRsp，其關(guān)鍵字段Result賦值為0，通知網(wǎng)關(guān)，然后網(wǎng)關(guān)通知SP，一個正式的訂購關(guān)系流程完成。如果解析出的是其他命令字，如555(表示退定業(yè)務(wù))，則轉(zhuǎn)到退定業(yè)務(wù)流程；如果是其他字母，則不做處理。

批價、扣費流程放在Charge模塊中處理，需要交互的信息通過進程間發(fā)送消息來完成通信。Charge模塊把處理的結(jié)果通過消息發(fā)往UIDB模塊，UIDB模塊最后再把結(jié)果以協(xié)議消息的形式發(fā)回網(wǎng)關(guān)。

對短信流程的改進主要集中在增加二次確認流程上，常規(guī)的夢網(wǎng)短信業(yè)務(wù)流程中沒有這個二次確認流程，這樣就給SP做假、強行給用戶訂閱上短信提供了可能。在我們的方案中，通過流程上的完善，使這種漏洞不復(fù)存在，使移動運營商從對SP的弱管理模式過渡到對SP的強管理模式。二次流程的實現(xiàn)可以在移動數(shù)據(jù)業(yè)務(wù)平臺的UIDB模塊和Charge模塊通過改動和增加這部分流程即可。

對一些非法和違規(guī)SP，我們可以通過設(shè)置一個黑白名單（黑名單用數(shù)據(jù)庫表BlackTable來記錄，白名單用表WhiteTable來記錄）。如果SP違規(guī)達到一定限度閾值，就把它加入黑名單中；如果SP的信用度很高，就可以加入白名單中，這樣在業(yè)務(wù)流程中通過SP的級別就可以控制流程。如果SP屬于白名單，則在具體流程中，如定制流程和點播流程中就可以省去對SP的鑒權(quán)環(huán)節(jié)，即跳過SPAuth()函數(shù)的調(diào)用。這樣可以加快業(yè)務(wù)響應(yīng)速度，提高系統(tǒng)性能。

對SP給用戶Push的MT消息，我們?yōu)榱私鉀QSP發(fā)不健康、不文明、反動言論等垃圾短信，我們在Push鑒權(quán)的過程中增加對短信內(nèi)容關(guān)鍵字進行過濾流程，用函數(shù)KeyWordFilter()來封裝實現(xiàn)，如果匹配到設(shè)置的關(guān)鍵字，則返回False，即禁止Push下去。通過增加這一個處理步驟，垃圾短信就可以制止。

3．2Session緩沖機制、多線程技術(shù)在開發(fā)中的應(yīng)用

為了提高系統(tǒng)的響應(yīng)速度和處理速度，平臺系統(tǒng)采用了自定義結(jié)構(gòu)的多個Session，如前所述如TAuthPriceReqSession，TAuthPriceCnfmReqSession，TChargeSession和TChargePriceSession，每個Session都有它自己的數(shù)據(jù)結(jié)構(gòu)和自己不同的各個Session狀態(tài)，每個不同的Session為一個具有多個邏輯狀態(tài)的抽象實體。通過event（）函數(shù)操作來實現(xiàn)各個Session狀態(tài)的遷移，各個業(yè)務(wù)流程執(zhí)行到哪里，可以通過查詢對應(yīng)Session的狀態(tài)數(shù)據(jù)得知。同時各個Session緩沖機制的使用，在內(nèi)存中及時保存了在一次會話中要使用的關(guān)鍵數(shù)據(jù)，減少了訪問后臺數(shù)據(jù)庫的次數(shù)，從而提高了系統(tǒng)響應(yīng)速度，降低了訪問別的進程帶來的數(shù)據(jù)延遲。

使用多線程的理由之一是與進程相比，它是一種非常“節(jié)儉”的多任務(wù)操作方式。據(jù)統(tǒng)計，一個線程的開銷大約是一個進程開銷的1/30左右。使用多線程的理由之二是線程間方便的通信機制。另外，與進程比較，多線程程序作為一種多任務(wù)、并發(fā)的工作方式，還有提高應(yīng)用程序響應(yīng)、使多CPU系統(tǒng)更加有效以及改善程序結(jié)構(gòu)等優(yōu)點［7］。UNIX（Linux）系統(tǒng)下的多線程遵循POSIX線程接口，稱為Pthread。

在我們的平臺系統(tǒng)中，UIDB主從進程和Charge主從進程都做成多線程的并發(fā)方式，這樣可以大大提高系統(tǒng)的性能，使業(yè)務(wù)處理速度加快、系統(tǒng)響應(yīng)速度加快。但是多線程也有它的缺點，如果線程使用不當，則會給系統(tǒng)帶來潛在的問題，所以必須根據(jù)需要慎用。

4結(jié)論

移動數(shù)據(jù)業(yè)務(wù)平臺(MDSP)是3G數(shù)據(jù)業(yè)務(wù)網(wǎng)絡(luò)解決方案中的核心部件，在其上實現(xiàn)短信增值業(yè)務(wù)的開發(fā)是為了實現(xiàn)其對業(yè)務(wù)的控制。這種流程控制體系采用各Session緩沖加狀態(tài)的這種抽象實體，使得業(yè)務(wù)流程結(jié)構(gòu)清晰、響應(yīng)速度加快。采用多線程技術(shù)提高了系統(tǒng)的性能。通過短信增值業(yè)務(wù)（如訂購、點播業(yè)務(wù)）流程的改進，在訂購業(yè)務(wù)流程中增加二次確認流程，使用黑白名單功能等加強了對SP的監(jiān)督和管理。移動數(shù)據(jù)業(yè)務(wù)平臺在數(shù)據(jù)網(wǎng)絡(luò)中的投入使用，從根本上改變了短信增值業(yè)務(wù)的運營模式，由對SP的弱管理模式轉(zhuǎn)變?yōu)閷P的強管理模式，這樣從計費、業(yè)務(wù)費率、業(yè)務(wù)關(guān)系等方面做了重新調(diào)整，從根本上控制了SP亂收費、欺詐用戶的行為，其核心控制功能主要放在其中的兩個模塊UIDB和Charge中。本文的開發(fā)方法和研究內(nèi)容在具體的項目中得到了很好的應(yīng)用，實踐證明完全可行。移動數(shù)據(jù)增值業(yè)務(wù)的開發(fā)和應(yīng)用將是電信增值業(yè)務(wù)開發(fā)的重點和熱點。

參考文獻：

［1］鄧永紅.3G技術(shù)綜述［J］.有線電視技術(shù)，2004，19:5．

［2］張欣，曲志峰.移動數(shù)據(jù)增值業(yè)務(wù)運營現(xiàn)狀及新一代增值業(yè)務(wù)平臺OSE［J］.移動通信，2004，28（4）:5962．

［3］中國移動通信集團公司.中國移動通信互聯(lián)網(wǎng)短信網(wǎng)關(guān)接口協(xié)議，CMPPv3.0.0(ChinaMobilePeertoPeer)［S］.2004．

［4］中國聯(lián)合通信公司.中國聯(lián)合通信公司短消息網(wǎng)關(guān)系統(tǒng)接口協(xié)議，SGIPv1.2(ShortMessageGatewayInterfaceProtocol)［S］.2001．

［5］中國電信集團公司.中國電信集團公司企業(yè)標準CT/T12001基于固定電話網(wǎng)的信息終端及綜合信息系統(tǒng)技術(shù)規(guī)范(第7分冊)短消息網(wǎng)關(guān)協(xié)議，SMGPv1.3(ShortMessageGatewayProtocol)［S］.2001．

［6］中國網(wǎng)絡(luò)通信集團公司.中國網(wǎng)絡(luò)通信集團公司企業(yè)標準PHS短消息網(wǎng)關(guān)技術(shù)規(guī)范(第1分冊)，短消息網(wǎng)關(guān)與服務(wù)提供商(SP)接口規(guī)范，CNGPv2.0(ChinaNetcomShortMessageGatewayProtocol)［S］.2004．

［7］張鳳梅，洪運國.Linux下的多線程編程方法研究［J］.大連民族學院學報，2005，7(1):79.

［8］廖俊平.基于CMPP協(xié)議的短消息平臺的設(shè)計與實現(xiàn)［D］.成都：西南交通大學，2004．

［9］張杰，陽富民，涂剛.嵌入式圖形系統(tǒng)NanoX多線程改造［J］.計算機工程與設(shè)計，2005，26(1):259261．

［10］[美]WRichardStevens.AdvancedProgrammingintheUNIXEnvironment［M］.Beijing:ChinaMachinePress，2002．

［11］[美]WRichardStevens.UNIXNetworkProgrammingvolume2:InterprocessCommunications(2ndedition)［M］.PrenticeHall，2002．

［12］SMSForum.ShortMessagePeertoPeerProtocolSpecificationversion5.0［EB/OL］.http://www.smsforum.net．

作者簡介：

劉永平(1978)，男，陜西府谷人，碩士研究生，研究方向為數(shù)據(jù)庫、計算機網(wǎng)絡(luò)與通信、移動通信技術(shù)、系統(tǒng)體系結(jié)構(gòu)；汪林林(1945)，男，安徽人，重慶市軟件協(xié)會副理事長，重慶市信息協(xié)會專家委員會副主任，重慶信息產(chǎn)業(yè)專家組成員，教授，碩導(dǎo)，副博導(dǎo)，主要研究方向為數(shù)據(jù)庫與數(shù)據(jù)挖掘、空間數(shù)據(jù)庫與GIS、計算機網(wǎng)絡(luò)、電信增值業(yè)務(wù)、系統(tǒng)體系結(jié)構(gòu)、軟件與理論。