賈正鋒,楊劍,(中國科學(xué)院 沈陽計算技術(shù)研究所,沈陽 068)(中國科學(xué)院大學(xué),北京 00049)

?

移動端融合通信中企業(yè)通訊錄增量更新的研究①

賈正鋒1,楊劍1,2
1(中國科學(xué)院 沈陽計算技術(shù)研究所,沈陽 110168)
2(中國科學(xué)院大學(xué),北京 100049)

摘 要:近年來,隨著移動互聯(lián)網(wǎng)的快速發(fā)展,通信行業(yè)也進入了移動時代,企業(yè)的通信業(yè)務(wù)可以借助移動互聯(lián)網(wǎng)結(jié)合融合通信拓展到移動領(lǐng)域.企業(yè)通訊錄作為企業(yè)通信的入口起著至關(guān)重要的作用.傳統(tǒng)的企業(yè)通訊錄更新技術(shù)未考慮到移動互聯(lián)網(wǎng)資源有限的特點已經(jīng)不適合用于目前的融合通信中.因此本文提出了基于LDAP目錄服務(wù)實現(xiàn)增量更新的方法,以此來降低移動端和服務(wù)器端的資源消耗.最后通過將傳統(tǒng)的企業(yè)通訊錄中全量更新技術(shù)與本文提出的增量更新技術(shù)作實驗對比分析,驗證增量更新在移動互聯(lián)網(wǎng)方面優(yōu)于全量更新.

關(guān)鍵詞:移動互聯(lián)網(wǎng); 融合通信; LDAP; 增量更新

融合通信中企業(yè)通訊錄(下稱通訊錄)作為企業(yè)核心通信業(yè)務(wù)的入口,起著至關(guān)重要的作用; 隨著最近幾年移動互聯(lián)網(wǎng)的快速發(fā)展,企業(yè)的通訊業(yè)務(wù)也拓展到移動領(lǐng)域,移動互聯(lián)網(wǎng)的一大特點是資源有限如流量、功耗以及傳輸?shù)?所以,企業(yè)通訊錄的實時更新對移動端是一項新的挑戰(zhàn)[1].

目前各大廠商都提出了各自的統(tǒng)一通訊解決方案,其中采用的通訊錄技術(shù)各有千秋.基于CPM 架構(gòu)的平臺基本采用融合地址薄的技術(shù)來實現(xiàn)通訊錄的功能,其它方案則大多采用私有協(xié)議來實現(xiàn)通訊錄功能[2-4].傳統(tǒng)通訊錄技術(shù)只是針對個人通訊錄,并沒有考慮到企業(yè)通訊錄需要對企業(yè)用戶進行訪問權(quán)限控制這一特殊性,并且提出之時并沒有智能移動設(shè)備和這些設(shè)備的應(yīng)用場景,都是針對于PC端提出的,采用的通訊錄更新技術(shù)都是全量更新,沒有考慮到目前移動移動互聯(lián)網(wǎng)資源有限的特點; 如果采用傳統(tǒng)的針對PC端的通訊錄技術(shù)必將導(dǎo)致移動終端流量消耗過多,功耗損失過快、服務(wù)器壓力過大; 以上兩大難題正是本文需要解決的; 本文提出了一種針對于企業(yè)移動終端通訊錄更新的解決方案-增量更新通訊錄技術(shù)[5-7]; 該方案通過采用LDAP協(xié)議提供通訊錄服務(wù)[8,9],并結(jié)合本文提出的role/type模型可以進行版本控制[10-13]從而實現(xiàn)增量更新模型.此既考慮到了企業(yè)通訊錄的特殊性,又針對移動互聯(lián)網(wǎng)進行了優(yōu)化,從而降低移動端和服務(wù)端的,資源消耗.

本文首先論述了通訊錄的特點,并根據(jù)這些特點對版本進行建模,隨后提出增量更新的具體實現(xiàn),并最終通過將傳統(tǒng)的更新方式即全量更新方式與本文提出的增量更新方式進行對比實驗以及對實驗結(jié)果的分析,論證了本方案的合理性可行性以及優(yōu)越性.

1　企業(yè)通訊錄的特點

1.1企業(yè)通訊錄的結(jié)構(gòu)

企業(yè)通訊錄與個人通訊錄不同,由于企業(yè)員工職位的不同導(dǎo)致企業(yè)通訊錄呈現(xiàn)出分層樹狀結(jié)構(gòu); 傳統(tǒng)的關(guān)系型數(shù)據(jù)庫不適合存儲這類結(jié)構(gòu),LDAP (Lightweight Directory Access Protocol)協(xié)議即輕量級目錄訪問協(xié)議用來提供目錄服務(wù),LDAP協(xié)議優(yōu)化了數(shù)據(jù)庫的讀速度,提供較高的讀操作效率,而通訊錄服務(wù)的一個特點是有很高的讀操作,所以本文采用LDAP協(xié)議的開源實現(xiàn)openLDAP[14-16]來實現(xiàn)通訊錄的存取訪問.

1.2企業(yè)通訊錄服務(wù)的特點及難點

通訊錄服務(wù)系統(tǒng)中企業(yè)的整個通訊錄存儲在服務(wù)器的數(shù)據(jù)庫中,但是由于企業(yè)員工訪問權(quán)限的不同,導(dǎo)致每個員工的通訊錄可能不同,從而導(dǎo)致在服務(wù)器通訊錄發(fā)生變化時只能更新受到影響的用戶.這既是企業(yè)通訊錄的特點又是本方案的難點所在; 通訊錄的同步一般體現(xiàn)在兩種場景中,場景一是當(dāng)管理員改變了企業(yè)通訊錄某員工信息或終端改變了自己的信息,服務(wù)器需要對受到影響的各終端通訊錄版本進行信息同步.場景二是用戶每次登錄時需要驗證自己的通訊錄版本是否是最新版本,若不是則需要從服務(wù)器中獲得最新版本通訊錄.

若用傳統(tǒng)的更新方式即全量更新方式,當(dāng)通訊錄發(fā)生變化時,服務(wù)器端需要重新從數(shù)據(jù)庫獲得用戶最新版本通訊錄,再把信息推送給受影響的用戶; 這無論是對服務(wù)器還是對移動端都會帶來不小的開銷; 為此本文提出兩種模型實現(xiàn)增量更新來減少傳統(tǒng)更新方式所帶來的各種資源開銷.

2　增量更新

2.1role/type模型

本文前面提到過企業(yè)通訊錄的一個特點是每位員工所能看到的企業(yè)通訊錄范圍不同,導(dǎo)致員工的通訊錄可能不同.因此,我們需要對員工的訪問的權(quán)限進行控制,同樣當(dāng)服務(wù)器通訊錄發(fā)生變化時只能更新受到影響的用戶.

為此本文提出了role/type模型,利用role/type模型可以完成用戶的訪問權(quán)限控制和定向更新通知.

圖1顯示的是一個利用role/type模型進行訪問控制的的示例圖.在創(chuàng)建員工時,我們會給每位員工分配至少一個role和一個type作為成員角色和成員類型,給每個部門分配一個type,我們就可以通過建立role 和type的映射關(guān)系來控制訪問權(quán)限,每個role會映射到一條訪問規(guī)則,在訪問規(guī)則中規(guī)定了這類role的兩個屬性: 一個是可以訪問哪類type的部門,另一個是可以訪問哪類type的員工.

圖1　企業(yè)結(jié)構(gòu)圖示例

圖1中如果我們想使角色為r1的用戶訪問部門p1、p2下的e2、e3類成員,角色為r2的用戶訪問部門 p1、p4下的e1、e3類成員,角色為r3的用戶訪問部門 p2、p3下的e1、e2類成員,角色為r4的用戶訪問部門 p5、p6下的e3類成員; 建立如表1所示的role/type關(guān)系即可.

如p2部門下的e2類型員工的信息發(fā)生變化,則根據(jù)反向映射可得需要通知的角色,本示例中需要通知角色為r1和r3類員工.

表1　role/type 模型權(quán)限控制表

2.2版本控制模型

本節(jié)描述版本控制模型,采用版本控制就需要引入版本號的概念,首先介紹下版本控制的相關(guān)定義:

定義1.終端版本號: 指用戶當(dāng)前在終端上使用的通訊錄版本的版本號

定義2.標(biāo)準(zhǔn)版本號: 指服務(wù)器上存儲的用戶最新通訊錄版本的版本號

定義3.企業(yè)通訊錄: 指存儲在服務(wù)器數(shù)據(jù)庫上整個企業(yè)的通訊錄.

定義4.終端通訊錄: 指某個用戶根據(jù)他的訪問權(quán)限能夠從企業(yè)通訊錄中獲得的通訊錄.

定義5.版本變更記錄: 指記錄引起標(biāo)準(zhǔn)版本號變化的變更信息.

3.2.1版本變更記錄表

當(dāng)企業(yè)通訊錄或role/type關(guān)系發(fā)生變更時,我們會將受到影響的用戶的標(biāo)準(zhǔn)版本號進行加一,并創(chuàng)建版本變更記錄表,用來記錄下用戶變化的信息.如表2所示.

表2 版本變更記錄表

通過版本控制模型建立版本變更記錄表我們就可以實現(xiàn)差量更新.

2.3通訊錄服務(wù)體系結(jié)構(gòu)

本文提出的企業(yè)通訊錄服務(wù)系統(tǒng)由移動終端用戶、管理端、中心服務(wù)器、和數(shù)據(jù)庫組成如圖2給出的是本文提出的通訊錄服務(wù)系統(tǒng)的體系結(jié)構(gòu):

圖2　通訊錄服務(wù)系統(tǒng)體系結(jié)構(gòu)圖

3　增量更新的示例

本文提出的增量更新體現(xiàn)在兩個場景中,場景一是當(dāng)終端用戶改變自己的信息如簽名或者管理人員改變員工信息時需要告知服務(wù)器,以便服務(wù)器及時將變更發(fā)送給受到影響的終端用戶實現(xiàn)增量更新,二是當(dāng)終端在登錄時會將終端版本號發(fā)送到服務(wù)器與標(biāo)準(zhǔn)版本號最對比,若不一樣,則將變更記錄中變更發(fā)送給終端用戶實現(xiàn)增量更新.如下圖所示: 場景1中當(dāng)終端A在改變了自己的簽名時會通知服務(wù)器,服務(wù)器會更新A在LDAP數(shù)據(jù)庫中的簽名信息,并通過role/type的關(guān)系找到被影響的終端D、E和F,隨后服務(wù)器會將D、E和F的標(biāo)準(zhǔn)版本號加一,并記錄下改變簽名這一變更,最后將這一變更以增量更新的方式發(fā)送到D、E和F,但F當(dāng)時不在線未收到變更通知.最后終端E和F更新A的簽名信息.場景1中,當(dāng)F上線時服務(wù)器會將F的終端版本號與標(biāo)準(zhǔn)版本號最對比,發(fā)現(xiàn)標(biāo)準(zhǔn)版本號較新,服務(wù)器從變更記錄數(shù)據(jù)庫中查找到F的變更記錄,發(fā)現(xiàn)是通訊錄中A的簽名發(fā)生改變,隨后從LDAP數(shù)據(jù)庫中取出A的簽名信息發(fā)送給F實現(xiàn)增量更細(xì).流程圖如圖3所示.

圖3　增量更新示例圖

4　實驗分析

本節(jié)主要對本文提出的針對移動端的增量更新與傳統(tǒng)的針對PC端的全量更新做實驗對比,本文主要做移動端消耗流量、功耗以及服務(wù)器性能的對比.

本文提出的面向移動端實現(xiàn)增量更新的設(shè)計已經(jīng)在項目中的服務(wù)器中實現(xiàn),為了驗證本文提出的增量更新能更好的適應(yīng)移動互聯(lián)網(wǎng),我們通過設(shè)計實驗將增量更新與傳統(tǒng)的全量更新方式對比.通過在服務(wù)器端使用wireshark抓包,分析數(shù)據(jù)包[17],在流量消耗和性能上做出了對比.

4.1增量更新測試

終端我們模擬100部智能手機代表100個用戶且這100個用戶可以相互看到,起初70個用戶在線,30個用戶離線,我們改變其中一個在線用戶的簽名,我們統(tǒng)計出服務(wù)器完成通知所消耗的流量,這個過程也就是上文中所描述的增量更新1的場景,然后讓這30個用戶上線,統(tǒng)計出服務(wù)器端的流量消耗,此過程也就是上文中所描述的增量更新2的場景.

通過以上這個測試環(huán)境我們分別測試出增量更新和全量更新分別所消耗的流量.如圖4和圖5所示.

圖4　場景1的流量對比

圖5　場景2的流量對比

由于全量更新是當(dāng)用戶的信息發(fā)生改變時服務(wù)器會將各個終端通訊錄發(fā)送給受到影響的用戶.而增量更新僅僅只是將終端通訊錄中發(fā)生的變化信息發(fā)送給受到影響的用戶,所以全量更新的流量消耗遠(yuǎn)遠(yuǎn)高于增量更新.

4.2性能測試

本文提出的增量更新被用于前文所述的兩個場景中,因此,在性能測試中我們同樣測試在兩個場景中全量更新和增量更新各自的性能情況.我們主要通過逐漸增加移動終端數(shù)量來統(tǒng)計內(nèi)存使用量、cpu占用率以及響應(yīng)時間(服務(wù)器更新推送完畢所用時間).實驗所用服務(wù)器配置如表3所示.

表3　服務(wù)器端配置

下圖表4顯示的是場景1中的增量更新(ID)和全量更新(FD)的性能測試結(jié)果表,表5所示的是場景2中的增量更新(ID)和全量更新(FD)的性能測試結(jié)果,從兩張表中看出無論是哪個場景響應(yīng)時間和cpu使用率增量更新遠(yuǎn)遠(yuǎn)小于全量更新,但是為了記錄變更記錄增量更新消耗了一點內(nèi)存,但是可以換得更好的時間和傳輸效率.

表4　場景1性能對比

表5　場景2性能對比

4.3功耗測試

以上給出的是服務(wù)端和客戶端在實驗中的一些性能和流量消耗的對比圖,本實驗為了更加突出本方案的優(yōu)勢對移動端的功耗也進行了測試[18],實驗場景以4.1中設(shè)計的為基礎(chǔ),功耗統(tǒng)計如圖6所示.

從圖6看出,隨著時間推移,增量更新的功耗明顯小于傳統(tǒng)的全量更新技術(shù).

圖6

5　總結(jié)

針對目前融合通信中傳統(tǒng)企業(yè)通訊錄的更新技術(shù)在流量、功耗和傳輸上不能很好地適應(yīng)移動互聯(lián)網(wǎng),本文主要提出了基于LDAP目錄服務(wù)實現(xiàn)增量更新的方法.本文首先提出通過建立role/type模型來進行通訊錄訪問權(quán)限控制,并且通過這一模型來達到定向更新通知; 隨后提出了,版本控制模型,通過版本控制模型我們可以進行版本對比并且結(jié)合版本變更記錄表和role/type關(guān)系實現(xiàn)定向差量化更新.使得增量更新消耗更少的流量和功耗從而更加適合于移動互聯(lián)網(wǎng);但是,增量更新也有不足之處,為了達到增量更新我們需要記錄版本號和變更記錄,這會消耗部分服務(wù)器資源以及增加了我們維護的難度,并且為了達到增量更新,客戶端需要設(shè)計更新解析器,這無疑會給客戶端帶來負(fù)擔(dān).

參考文獻

1韓秀紅,張全英.基于企業(yè)單位通訊錄系統(tǒng)設(shè)計與實現(xiàn).硅谷,2012,(17):2.

2柏祖進.XCAP協(xié)議研究.中國科技信息,2008(14):121–125

3Benoit Marchal SAX.The power API.http://www.im.com/ developerworks/xml/library/x-saxapi/2001.

4 YD/T 2013.基于Android的統(tǒng)一通信移動終端技術(shù)研究.

5張蓮,李京.云同步系統(tǒng)中采用增量存儲的版本控制技研究.小型微型計算機系統(tǒng),2015,(36):109-112.

6Wu XY,Li HN.Remote backup system based on file type.Network & Computer Security,2012,(3): 40–42

7Xu D,Sheng YH,Ju DP.High effective two-round remote file fast synchronization algotithm.Journal of Frontiers of Computer Science and Technology,2011,5(1): 38–49

8任軍.基于LDAP的目錄服務(wù)綜述.計算機應(yīng)用研究,2005,(5):48–53

9Lightweight Directory Access Protocol (LDAP).IETF,RFC4519,June 2006

10付喜梅,陳家新.協(xié)同設(shè)計中版本存儲控制策略的研究.微計算機信息,2006,(12):105–108.

11楊富玉,單純.大型數(shù)據(jù)庫應(yīng)用系統(tǒng)的版本控制設(shè)計與實現(xiàn).計算機應(yīng)用,2003(7):102–104.

12劉黎志,劉軍.時變維度層次版本控制方法研究.計算機應(yīng)用,2007(1):79–83

13The OpenLDAP Project Web Site.http://www.openldap.org/project/.

14Active Directory Services Interface(ADSI).http://msdn.microsoft.com.

15Timothy AH,Smith MC,et al.Understanding and Deploying LDAP Directory Services,Second Edition.USA: Addison -Wesley Pub Co.,2003.

16王群.計算機網(wǎng)絡(luò)安全技術(shù).北京:清華大學(xué)出版社,2011.

17李建偉,劉臻,來志京,尹豐.基于用戶體驗的智能手機功耗測試研究.電信網(wǎng)技術(shù),2014(10):3–5.

Research of Business Contacts Incremental Update in Unified Communications for Mobile Internet

JIA Zheng-Feng1,YANG Jian1,2
1(Shenyang Institute of Computer Technology,Chinese Academy of Sciences,Shenyang 110168,China)2(University of Chinese Academy of Sciences,Beijing 100049,China)

Abstract:In recent years,with the rapid development of mobile Internet,the telecommunications industry has entered the mobile era.Against this significant background,companies can make use of the mobile Internet and converge communication traffic to expand into the mobile field.As an entrance to corporate communication,the significance of business contacts can't be ignored.However,the limited characteristic of mobile Internet resources has not been paid attention to by the update technology of traditional.As a result,it is no longer conducive to the current converged communications.Therefore,this paper puts forward an incremental update methods based on LDAP directory service in order to reduce resources consumed in the mobile client and server side.In conclusion,an experimental and comparative analysis of the full amount update technology used in traditional corporate directory and incremental update technology presented in this paper is conducted with an aim to verify and confirm that the incremental update method applied in the mobile Internet gains advantages over the full amount of update.

Key words:mobile internet; unified communication; LDAP; incremental update

收稿時間:①2015-08-11;收到修改稿時間:2015-10-26