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

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

?

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

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

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

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

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

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

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

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

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

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

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

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

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

2　增量更新

2.1role/type模型

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

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

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

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

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

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

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

2.2版本控制模型

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

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

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

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

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

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

3.2.1版本變更記錄表

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

表2 版本變更記錄表

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

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

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

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

3　增量更新的示例

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

圖3　增量更新示例圖

4　實(shí)驗(yàn)分析

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

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

4.1增量更新測(cè)試

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

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

圖4　場(chǎng)景1的流量對(duì)比

圖5　場(chǎng)景2的流量對(duì)比

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

4.2性能測(cè)試

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

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

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

表4　場(chǎng)景1性能對(duì)比

表5　場(chǎng)景2性能對(duì)比

4.3功耗測(cè)試

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

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

圖6

5　總結(jié)

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

參考文獻(xiàn)

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

2柏祖進(jìn).XCAP協(xié)議研究.中國(guó)科技信息,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)一通信移動(dòng)終端技術(shù)研究.

5張蓮,李京.云同步系統(tǒng)中采用增量存儲(chǔ)的版本控制技研究.小型微型計(jì)算機(jī)系統(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ù)綜述.計(jì)算機(jī)應(yīng)用研究,2005,(5):48–53

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

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

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

12劉黎志,劉軍.時(shí)變維度層次版本控制方法研究.計(jì)算機(jī)應(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王群.計(jì)算機(jī)網(wǎng)絡(luò)安全技術(shù).北京:清華大學(xué)出版社,2011.

17李建偉,劉臻,來(lái)志京,尹豐.基于用戶體驗(yàn)的智能手機(jī)功耗測(cè)試研究.電信網(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

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