胡 鵬 夏 揚 曲愛妍

(中國電子科技集團公司第二十八研究所 南京 210007)

?

一種針對LDAP客戶端與服務器通信的改進方案*

胡 鵬 夏 揚 曲愛妍

(中國電子科技集團公司第二十八研究所 南京 210007)

論文提出了一種改進基于目錄訪問協(xié)議(LDAP)的客戶端與服務器的交互方法的方案?？蛻舳水惒降叵蚍斩税l(fā)送若干操作請求;服務端處理多個操作請求后,向客戶端發(fā)送各個操作請求對應的結果;客戶端反復檢測緩存,獲取服務端發(fā)來的操作結果等信息。論文解決了檢測接口因為頻繁被調(diào)用,嚴重影響性能的問題,提高客戶端的并發(fā)性能。

輕量級目標訪問協(xié)議; 目錄; 條目; 目錄信息樹; 異步

Class Number TP31

1 引言

輕量級目錄訪問協(xié)議(Lightweight Directory Access Protocol,LDAP)是實現(xiàn)提供被稱為目錄服務的信息服務[1]。目錄服務是一種特殊的數(shù)據(jù)庫系統(tǒng),其專門針對讀取,瀏覽和搜索操作進行了特定的優(yōu)化。目錄一般用來包含描述性的,基于屬性的信息并支持精細復雜的過濾能力[2～3]。目錄一般不支持通用數(shù)據(jù)庫針對大量的更新操作,這些操作需要復雜的事務管理或回卷策略[4]。而目錄服務的更新則一般都非常簡單。這種目錄可以存儲包括個人信息、web鏈結、jpeg圖像等各種信息。為了訪問存儲在目錄中的信息,就需要使用運行在TCP/IP之上的訪問協(xié)議LDAP[5～6]。

LDAP的信息是以樹型結構存儲的,在樹根一般定義國家(c=CN)或域名(dc=com),在其下則往往定義一個或多個組織(organization)(o=Acme)或組織單元(organizational units) (ou=People)。一個組織單元可能包含諸如所有雇員、大樓內(nèi)的所有打印機等信息。此外,LDAP支持對條目能夠和必須支持哪些屬性進行控制,這是有一個特殊的稱為對象類別(objectClass)的屬性來實現(xiàn)的。該屬性的值決定了該條目必須遵循的一些規(guī)則,其規(guī)定了該條目能夠及至少應該包含哪些屬性[7～8]。

通常情況下,客戶端要對目錄信息樹存儲和訪問必須包含應用層和LDAP適配層,它們之間用LDAP API作為接口進行通信[9～10],如圖1所示。

圖1 LDAP客戶端與服務器通信邏輯結構

客戶端進行增刪查改操作,同步或者異步調(diào)用標準接口。以下論述RFC1823對異步調(diào)用接口的定義。Ldap_add接口如下定義:

int ldap_add(LDAP *longd, char *dn, LDAPMod *attrs[]);

客戶端調(diào)用上述函數(shù),得到一個整型的返回值,下文稱為操作標識號。由于客戶端異步調(diào)用上述操作接口,所以客戶端只有定時調(diào)用LDAP_ResCheck接口檢查服務器端返回的結果,才能獲取本次操作是否成功。LDAP_ResCheck接口定義如下:

int ldap_rescheck(

LDAP *longd,

int messageid,

int all,

struct timestru *timeout,

LDAPMsg **result

);

增加兩個姓名“HUANG”和“HU”,如圖2所示的流程。從圖2所示的流程可以看到,LDAP_ResCheck被調(diào)用了兩次。也就是說如果要增加N個字符串,則LDAP_ResCheck接口會被調(diào)用N次。對LDAP_ResCheck進行調(diào)用,都會經(jīng)歷一個短暫的時間,這個時間就是由struct timestru *timeout定義的。很明顯,如果LDAP_ResCheck調(diào)用次數(shù)過多,勢必嚴重影響性能。

圖2 異步調(diào)用示例

因此,為了提高LDAP客戶端的處理性能,本文提出一種交互方法,有效解決LDAP_ResCheck調(diào)用次數(shù)多而影響性能的問題。

2 現(xiàn)行系統(tǒng)結構

如圖3所示,LDAP客戶端向服務器端添加一條數(shù)據(jù)的流程如下:

圖3 改進后應用示例

1) LDAP客戶端調(diào)用ldap_add接口,向服務器端發(fā)送增加數(shù)據(jù)的請求,本次請求以messageid=1標識;LDAP客戶端此時尚不清楚增加數(shù)據(jù)項是否成功;

2) LDAP服務器端處理添加數(shù)據(jù)的請求后將處理結果發(fā)送給LDAP客戶端,用messageid=1標識操作結果,該操作結果保存在LDAP客戶端的緩沖區(qū)中,供客戶端檢測相應messageid的結果;

3) LDAP客戶端定時調(diào)用ldap_rescheck接口,檢測緩沖區(qū)是否存在服務器端發(fā)送來的對應messageid=1的響應;如果檢測到,則根據(jù)操作結果進行后面的處理。

根據(jù)上述流程可以看到,倘若LDAP_ResCheck調(diào)用次數(shù)越多,很明顯就會降低LDAP客戶端的處理性能。因此,本文提出了一種LDAP客戶端與服務器通信方式,旨在客戶端與服務器建立可信鏈接后,對目錄信息樹中的數(shù)據(jù)項進行操作,主要通過修改LDAP_ResCheck接口來解決上述多次調(diào)用帶來的性能瓶頸問題。

3 改進方案

LDAP客戶端與服務器通信流程如下:

1) 客戶端隨機向服務器發(fā)送多個操作請求;操作請求可以包括如下任一種:增加、刪除、修改等;

2) 服務器收到操作請求后,處理若干個操作請求,隨即向客戶端發(fā)送各個操作請求對應的結果;

3) 客戶端在緩沖區(qū)中尋找請求結果,確定服務器返回了哪些操作請求對應的請求結果。

需要說明的是,上述每個操作請求都具有唯一的標識號,而操作請求對應的請求結果也具有相同的標識號?？蛻舳烁鶕?jù)操作請求的標識號在緩沖區(qū)中尋找具有此標識號的請求結果。

客戶端定時在緩沖區(qū)中查找操作結果,有以下兩種情況:

一種是客戶端在緩沖區(qū)中找到了所有的操作請求對應的請求結果時,客戶端把所有請求結果發(fā)送到應用層;應用層根據(jù)操作請求標識號分析其對應請求結果。

另一種,當客戶端查找緩沖區(qū)時發(fā)現(xiàn)并不是所有操作請求全部返回了操作結果,客戶端將重復在緩沖區(qū)中尋找,直到檢測到所有操作標識號都已返回結果;隨后依次將所有請求結果發(fā)送給應用層;應用層根據(jù)操作請求的標識號查找其對應請求結果。

在客戶端放置結果查詢定時器(timer);當發(fā)現(xiàn)服務端并未發(fā)送所有操作的結果時,查看查詢定時器,若是沒有超時(timeout),那么客戶端將不斷查找緩沖區(qū)。在查詢定時器timeout前服務器發(fā)送了所有操作的結果,客戶端把所有操作結果發(fā)送到應用層;在查詢定時器超時后服務端并未發(fā)送所有操作結果給客戶端,那么客戶端會向應用層發(fā)送操作失敗的消息。

基于上述內(nèi)容,具體實現(xiàn)過程如下:

客戶端(client)通過異步執(zhí)行的方式對目錄信息樹中的數(shù)據(jù)項做修改操作;保存所有執(zhí)行記錄的操作標識號messageid;

服務器端(server)收到客戶端發(fā)來的操作請求,異步處理完畢后,把各個請求結果按它們的messageid發(fā)送到客戶端;

客戶端(client)通過LDAP_ResCheck接口,查找緩存中對應操作標識號messageid的結果是否存在;倘若所有操作結果均被返回,那么就會向應用層發(fā)送LDAP_ResCheck調(diào)用結果;否則客戶端在超時前循環(huán)檢測緩沖區(qū),停止條件是定時器超時或者所有操作結果均已返回到客戶端。

應用層檢測結果緩沖區(qū),用messageid區(qū)別各個操作請求的結果,做出相應后續(xù)處理。

4 應用示例

下文給出了一個實現(xiàn)例子,參考圖2和圖3,應用背景是客戶端向服務端發(fā)起增加兩個字符串的操作,基于LDAP協(xié)議的應用系統(tǒng)進行以下處理:

1) 客戶端向服務端異步發(fā)起增加數(shù)據(jù)項(增加“HUANG”)的操作請求,設定該操作請求的操作標識號為messageid=1;客戶端此時并不清楚增加的數(shù)據(jù)項操作是否已經(jīng)成功;

2) 客戶端向服務端異步發(fā)起增加數(shù)據(jù)項(增加”HU”)的操作請求,設定該操作請求的操作標識號為messageid=2;同樣,客戶端此時并不清楚增加的數(shù)據(jù)項操作是否已經(jīng)成功;

3) 服務器收到客戶端發(fā)送的兩個操作請求,進行并發(fā)處理,處理完之后將兩個請求結果用它們的messageid(1,2)進行標識,以異步的方式發(fā)送給客戶端;

4) 客戶端調(diào)用LDAP_ResCheck,在其緩沖區(qū)中的messageid數(shù)組中查找對應操作的標識號;倘若所有的操作響應均已收到,客戶端將標識號對應的結果發(fā)送給應用層;若并未收到所有操作標識號對應的響應內(nèi)容,客戶端將反復檢測緩存,一直等到超時或者所有的操作結果都已返回。

如圖4所示,該應用系統(tǒng)主要包含:

圖4 應用系統(tǒng)組成

1) 操作發(fā)送組件,在客戶端中,異步地向服務端發(fā)送操作請求;

2) 請求處理組件,在服務端,處理客戶端發(fā)來的操作請求,處理完后發(fā)送操作請求的結果;

3) 緩存組件,在客戶端中,緩存服務器發(fā)來的請求結果;

4) 檢測組件,輪詢緩存,當服務端發(fā)送完畢所有操作請求的結果,檢測終止。

其中檢測組件包括:

1) 數(shù)組,存儲檢測組件檢測到的服務端發(fā)來的操作請求的結果;

2) 定時器一,控制檢測緩存的時間;

3) 定時器二,檢測組件在定時器一的周期內(nèi)查找緩存,但若定時器二超時,停止輪詢查找。

5 結語

本文提出了一種基于目錄訪問協(xié)議(LDAP)客戶端與服務端交互方法的改進方案,該系統(tǒng)包括:客戶端,異步向服務端發(fā)送操作請求,把服務端發(fā)送來的操作請求對應的結果存儲在緩存中;服務器端,接收客戶端發(fā)來的操作請求,負責處理完畢后發(fā)送操作結果,各操作結果用各自操作標識號進行區(qū)別;客戶端檢測組件具體包括:操作結果檢測組件,在緩存中檢測操作請求的標識號(messageid)對應的操作結果,如果并非所有操作均返回結果,則在緩存中反復檢查,直至超時返回超時錯誤信息。

[1] The Open Source LDAP SuiteOpen LDAP[Z/OL].(2009-11-12)[2010-09-12] http://www.OpenLDAP.org.

[2] Directory Mark. The LDAP Server Benchmarking Too1, Information is available on the World Wide Web at[Z/OL].(2003-05-11) [2010-09-21] http://WWW.Mind-craft.com/directory mark.

[3] 王源.LDAP認證實現(xiàn)與性能分析[J].電子科技,2010,23(12):76-78.

[4] 任軍.基于LDAP的目錄服務綜述[J].計算機應用研究,2005(5):8-10.

[5] 涂德志.LDAP協(xié)議研究與LDAP服務器的設計與實現(xiàn)[D].成都:電子科技大學,2002.

[6] 王春耕,朱建濤.大規(guī)模機群系統(tǒng)中基于LDAP的用戶管理[J].計算機工程與應用,2004,40(18):47-49.

[7] 任軍.基于LDAP(輕量目錄訪問協(xié)議)的目錄服務綜述[J].計算機應用研究,2005(5):8-10.

[8] 張軍,顏凱.輕量級目錄訪問協(xié)議分析[J].計算機應用,1999(10):45-49.

[9] 許鑫,蘇新寧,陸炯.數(shù)字化校園身份認證系統(tǒng)的設計[J].現(xiàn)代圖書情報技術,2005(4):51-57.

[10] 王倩宜,李潤娥,李庭晏.統(tǒng)一用戶管理和身份認證服務的設計與實現(xiàn)[J].實驗技術與管理,2004,21(3):7-12.

參考文獻著錄規(guī)則

一.總要求

為了幫助向本刊投稿的作者按規(guī)范著錄參考文獻,現(xiàn)將常見類型文獻的著錄格式作如下要求。

本刊要求雙語參考文獻,所有的中文參考文獻均需附英文譯文,示例如下:

示例1:

[1] 焦李成,杜海峰,等．免疫優(yōu)化計算、學習與識別[M].北京:科學出版社,2006． JIAO Licheng, DU Haifeng, et al Immune optimization calculation 、Learning and Recognition [M]. Beijing: Science Pres,2006．

[2] 李詩靈,陳寧,趙學彧．基于粒子群算法的城市軌道交通接運公交規(guī)劃[J]．武漢理工大學學報(交通工程與科學版)2010,34(4)780-783． LI Shiling, CHEN Ning, ZHAO Xueyu． Planning of Feder Bus to the Urban Rail Transit Based on Particle Swarm Optimization[J]． Journal of Wuhan University of Technology(Transportation Science & Enginering),2010,34(4):780-783．

參考文獻中的責任者采用姓前名后的著錄形式。歐美著者的名可縮寫,姓大寫,姓和縮寫的名之間不可用“.”隔開,而是用空格。如用中譯名,可以只著錄其姓。如原文中作者為“P．S．昂溫”則在本刊要求中應寫成“昂溫 P S”,Albert Einstein Seny應寫成EINSTEIN A S。

參考文獻的責任者之間用“,”分隔。不超過3個時,全部照錄。超過3個時,只著錄前3個責任者,其后加“,等”,外文用“,et al”,“et al”不必用斜體。

示例2:馬克思,恩格斯．示例2:YELLAND R L, JONES S C, EASTON K S, et al．

二.圖書和期刊的著錄格式

◆ 普通圖書(原著): [序號]著者．書名[M]．版本(第1版不著錄)．出版地:出版者,出版年:引文頁碼． [3]余敏．出版集團研究[M]．北京:中國書籍出版社,2001:179-193． [4]中國社會科學院語言研究所詞典編輯室．現(xiàn)代漢語詞典[M]．修訂本．北京:商務印書館,1996:258-260． [5]CRAWFPRD GORMAN M． Future libries: dreams, madnes, &reality[M]． Chicago: America Library Asociation,1995．

◆ 普通圖書(譯著): [序號]著者．書名[M]．譯者,譯．版本．出版地:出版者,出版年:引文頁碼． [6]AGRAWAL G P． 非線性光纖光學[M]．胡國絳,黃超,譯．天津:天津大學出版社,1992:179-193． [7]霍斯尼 R K． 谷物科學與工藝學原理[M]．李慶龍,譯．2版．北京:中國食品出版社,1989:15-20．

◆ 期刊(有卷) [序號]著者.題名[J]．刊名,出版年份,卷(期)引文頁碼． [8]蔣超,張沛,張永軍,等．基于SRLG不相關的共享通路保護算法[J]．光通信技術,2007,31(7):4-6． [9]DIANOV E M, BUFETOV I A, BUBNOV M M, et al． Thre-cascaded 1407nm Raman laserbased on phosphorusdoped silica fiver[J]． OPTICS LETTERS,2000,26(6):402-404．

◆ 期刊(無卷) [序號]著者.題名[J]．刊名,出版年份(期):引文頁碼． [10]周可,馮丹,王芳,等．網(wǎng)絡磁盤陣列流水調(diào)度研究[J]．計算機學報,2005(3):319-325． [11]VLATK V, MARTIN B P． Basic of quantum compwtation[J]． Proces in Quantum Electronics,1998(22):1-39．

三.電子文獻的著錄格式

◆ 電子文獻: [序號]主要責任者．題名:其他題名信息[文獻類型標志/文獻載體標志]．出版地:出版者,出版年(更新或修改日期)[引用日期]．獲取和訪問路徑． [12]Online Computer Library Center, Inc． History of OCLC[EB/OL]．[2000-01-08]．htp://www．oclc．org． [11]蕭鈺．出版業(yè)信息化邁入快車道[EB/OL]．(2001-12-19)[2002-04-15]．htp:∥www．creader．com/news/200112190019．htm．

四.學位論文與論文集的著錄格式

◆ 學位論文: [序號]著者．題名[D]．出版地:出版者,出版年:引文頁碼． [13]孫玉文．漢語變調(diào)構詞研究[D]．北京:北京大學文學院,2000．

◆ 論文集: [序號]著者．題名[C]//著者．專題名:其他題名．出版地:出版者,出版年:引文頁碼． [14]白書龍．植物開花研究[C]//李承森．植物科學進展．北京:高等教育出版社,1998:146-163． [15]AZIEM M M A, ISMAIEL H M． Quantitative and qualitative Evaluations of Image Enhancement Techniques[C]//Procedings of the 46th IEEE International Midwest Symposium on Circuits and Systems,2003:664-669．

An Advanced Method of Communication Method between Client and Server Based on Directory Access Protocol

HU Peng XIA Yang QU Aiyan

(The 28th Research Institute of China Electronics Technology Group Corporation, Nanjing 210007)

This paper puts forword a kind of interactive method between client and server based on Lightweight Directory Access Protocol(LDAP). The client send request of multi-operation entry to the server successively, and the server processes request of multi-operation entry mentioned above in asynchronous way. At the same time,the server returns the result of request corresponding to the operation entry one by one. The client checks the buffer to judge the server whether return all the the result of request corresponding to the operation entry. This paper resolves that the LDAP_Result function is called by too many times in relevant technique, thereby advanced the LDAP client performance of processing entry.

LDAP, directory, entry, directory information tree, asynchronism

2014年7月11日,

2014年8月23日

胡鵬,男,助理工程師,研究方向:海量實時數(shù)據(jù)存儲訪問、數(shù)據(jù)庫管理技術。

TP31

10.3969/j.issn1672-9730.2015.01.018