并行計算機(jī)中基于令牌的許可證管理

曹宏嘉,盧宇彤,2

(1.國防科學(xué)技術(shù)大學(xué)計算機(jī)學(xué)院，湖南 長沙 410073;2.國防科學(xué)技術(shù)大學(xué)高性能計算國家重點(diǎn)實驗室，湖南 長沙 410073)

并行計算機(jī)中基于令牌的許可證管理

曹宏嘉1,盧宇彤1,2

(1.國防科學(xué)技術(shù)大學(xué)計算機(jī)學(xué)院，湖南 長沙 410073;2.國防科學(xué)技術(shù)大學(xué)高性能計算國家重點(diǎn)實驗室，湖南 長沙 410073)

提出一種適用于并行計算機(jī)系統(tǒng)的基于令牌的許可證管理模型。該模型將軟件許可證的使用顯式分開為申請與檢出兩步，許可證的釋放分開為檢入和回收兩步，并由資源管理系統(tǒng)代理軟件進(jìn)行許可證資源的申請和回收。在此模型中，軟件許可證的使用將由資源管理系統(tǒng)完全控制與調(diào)度，避免了現(xiàn)有模型中存在的資源管理系統(tǒng)外作業(yè)使用許可證、作業(yè)錯誤指定許可證信息、應(yīng)用進(jìn)程殘留等情景下，出現(xiàn)用戶作業(yè)因許可證不可用而造成的運(yùn)行失敗或資源浪費(fèi)。設(shè)計了兩種在現(xiàn)存遺留應(yīng)用軟件和許可證管理軟件上實現(xiàn)基于令牌的許可證管理模型的方法，充分表明了此模型的現(xiàn)實意義。

資源管理;作業(yè)調(diào)度;許可證管理;令牌

1 引言

現(xiàn)在的并行計算機(jī)一般使用資源管理系統(tǒng)RMS(Resource Management System)對系統(tǒng)中的各種資源進(jìn)行管理調(diào)度，分配給作業(yè)使用。在CAD、CAE等應(yīng)用領(lǐng)域，大部分第三方軟件都通過許可證機(jī)制進(jìn)行產(chǎn)權(quán)保護(hù)，控制軟件可以運(yùn)行的節(jié)點(diǎn)位置與/或可同時運(yùn)行的軟件副本數(shù)量。當(dāng)許可證不可用時，應(yīng)用軟件將報錯退出，或占用計算資源等待。在并行計算機(jī)的多用戶、多道作業(yè)環(huán)境下，許可證作為一種昂貴的軟件資源需要RMS調(diào)度作業(yè)時予以管理和調(diào)度分配，以避免在不合適的計算節(jié)點(diǎn)或時機(jī)加載作業(yè)運(yùn)行，導(dǎo)致作業(yè)由于許可證不足而運(yùn)行失敗或系統(tǒng)資源利用率低下。

由于現(xiàn)存的許可證管理軟件LM(License Manager)在設(shè)計時未能考慮到應(yīng)用軟件以作業(yè)的形式通過資源管理系統(tǒng)運(yùn)行， LM都未能提供與RMS交互的接口?，F(xiàn)在的RMS和LM大多使用一種通過RMS向LM輪詢可用許可證計數(shù)的方法，試圖保持RMS和LM的許可證可用計數(shù)的一致性。然而，由于應(yīng)用場景的復(fù)雜性，以及作業(yè)加載時間與軟件實際使用許可證的時間之間存在間隔，這種方法中存在競爭條件，并不能完全避免作業(yè)運(yùn)行失敗的情況。

本文提出一種基于令牌的許可證資源管理模型。通過將應(yīng)用軟件對許可證的使用分開為許可證資源分配和許可證檢出兩步，并允許RMS代理應(yīng)用軟件進(jìn)行許可證分配，此模型能夠有效解決并行計算機(jī)系統(tǒng)中RMS與LM共同進(jìn)行許可證資源管理的協(xié)同問題。模型的關(guān)鍵在于軟件在檢出許可證時需要以所分配的許可證令牌為憑證。文章給出了在現(xiàn)有遺留軟件與LM上實現(xiàn)基于令牌的許可證管理模型的兩種可行機(jī)制，表明此模型具有重要的現(xiàn)實意義。

2 許可證管理與資源調(diào)度

2.1 并行計算機(jī)系統(tǒng)資源調(diào)度

隨著并行計算技術(shù)的發(fā)展，高性能計算機(jī)越來越普及，并行系統(tǒng)的規(guī)模越來越大，應(yīng)用場景也越來越復(fù)雜。為了有效管理并行計算機(jī)系統(tǒng)中海量的計算、通信、I/O等資源，協(xié)調(diào)多用戶、多作業(yè)對資源的訪問，當(dāng)前的并行計算機(jī)系統(tǒng)一般都通過資源管理系統(tǒng)進(jìn)行作業(yè)調(diào)度與資源分配。資源管理系統(tǒng)負(fù)責(zé)監(jiān)控系統(tǒng)中各種資源的狀態(tài)與可用情況，并為用戶作業(yè)選擇合適的資源，調(diào)度其運(yùn)行。一般而言，在一個并行系統(tǒng)中資源管理系統(tǒng)是用戶使用和管理員管理資源的入口，系統(tǒng)限制不經(jīng)過RMS的資源使用，以維持系統(tǒng)狀態(tài)的一致性，避免資源沖突帶來的作業(yè)性能下降。

一般的資源管理系統(tǒng)在為作業(yè)分配資源時僅考慮到作業(yè)的處理器、內(nèi)存、磁盤空間等資源需求，某些系統(tǒng)會考慮節(jié)點(diǎn)負(fù)載、I/O及通信帶寬等。對于需要使用軟件許可證的第三方軟件，RMS在為用戶作業(yè)分配資源時就必須考慮其對許可證的需求，避免出現(xiàn)給用戶作業(yè)分配許可證不可用的節(jié)點(diǎn)，或者是調(diào)度作業(yè)運(yùn)行時許可證數(shù)目不足，導(dǎo)致作業(yè)無法運(yùn)行。而且，軟件許可證是一種昂貴的資源，其使用效率嚴(yán)重影響用戶的計算體驗。

2.2 軟件許可證管理

目前最常用的許可證管理軟件是FlexNet Publisher(FNP)，它是FlexLM的升級[1]。典型的由FNP控制的許可證使用場景與部署如圖1所示。

Figure 1 License management with FNP圖1 FNP的許可證管理

FNP Manager Daemon是許可證管理器守護(hù)進(jìn)程，負(fù)責(zé)與應(yīng)用程序進(jìn)行初始聯(lián)系，并連接到適當(dāng)?shù)能浖?yīng)商守護(hù)進(jìn)程。許可證管理器守護(hù)進(jìn)程還負(fù)責(zé)供應(yīng)商守護(hù)進(jìn)程的啟動。Vendor Daemon是供應(yīng)商守護(hù)進(jìn)程，負(fù)責(zé)監(jiān)視軟件許可證的使用。許可證文件中記錄了所授權(quán)的軟件許可證及其數(shù)目，可由管理員編輯。供應(yīng)商守護(hù)進(jìn)程可以有自己的配置文件。FNP管理服務(wù)還會生成許可證使用的一些日志用于調(diào)試或報表生成。

應(yīng)用軟件鏈接到FNP客戶端代碼，通過TCP/IP與FNP管理服務(wù)進(jìn)行交互。應(yīng)用軟件請求檢出(check-out)指定數(shù)目的許可證時，管理服務(wù)根據(jù)許可證文件配置和當(dāng)前許可證使用情況，許可或拒絕軟件對許可證的使用。根據(jù)軟件設(shè)計不同，在許可證使用被拒絕時，軟件可能報錯退出，或者占用計算資源等待。應(yīng)用軟件運(yùn)行完畢或使用許可證完畢后，將所使用的許可證檢入(check-in)，以供其它軟件后續(xù)使用。

FNP控制的許可證分為節(jié)點(diǎn)鎖定許可證和浮點(diǎn)許可證。節(jié)點(diǎn)鎖定許可證不限制使用數(shù)目，但僅在特定節(jié)點(diǎn)上可用。作業(yè)請求節(jié)點(diǎn)鎖定的許可證相當(dāng)于請求只能從一組特定節(jié)點(diǎn)中分配資源，目前的RMS均能處理這種需求。浮動許可證不限制使用許可證的位置，但限制最多同時并發(fā)使用許可證的數(shù)目。并行作業(yè)的許可證資源沖突主要由浮動許可證引起。下文的許可證管理即指浮動許可證的管理。

除FNP外，常用的LM還包括RLM[2]、Sentinel RMS[3]等；其工作原理和存在的問題與FNP類似。

2.3 問題與挑戰(zhàn)

大部分的 LM 都是商業(yè)軟件,并不提供開放接口進(jìn)行許可證的控制。例如，F(xiàn)NP中僅提供了一個命令行工具lmutil進(jìn)行許可證狀態(tài)查詢和簡單控制功能。這給LM和RMS的結(jié)合帶來了很大困難。而且，對軟件許可證的使用不是由LM完全控制，而是涉及多種多樣的應(yīng)用軟件。目前的RMS系統(tǒng)不能完全與LM協(xié)調(diào)，控制對軟件許可證的使用與分配。例如，在當(dāng)前版本的SLURM(Simple Linux Utility for Resource Management)[4]系統(tǒng)中，僅在RMS內(nèi)部對許可證的使用進(jìn)行簡單計數(shù)，而沒有與LM進(jìn)行交互。在LSF(Load Sharing Facility)[5]系統(tǒng)中，通過定期查詢LM中的許可證使用情況，以將軟件對許可證的使用反映到RMS中，作為作業(yè)調(diào)度決策依據(jù)。

不與LM進(jìn)行交互，或者僅查詢LM中可用的許可證數(shù)目，而不進(jìn)行訪問控制，很容易出現(xiàn)RMS中可用的許可證計數(shù)與LM中實際可用的計數(shù)不一致的情況。常見的原因[6]包括：

(1)用戶不分配資源，直接運(yùn)行應(yīng)用程序并占用許可證。由于RMS不能感知應(yīng)用程序?qū)υS可證的使用情況，這將導(dǎo)致RMS計數(shù)少于實際可用數(shù)目，提前調(diào)度作業(yè)運(yùn)行，導(dǎo)致作業(yè)運(yùn)行失敗。

(2)用戶作業(yè)實際使用許可證數(shù)目與申請分配的數(shù)目不一致。用戶提交作業(yè)時可能(無意或有意)指定錯誤的許可證數(shù)目。指定過多的許可證卻不使用將導(dǎo)致昂貴的許可證資源浪費(fèi)；指定過少的許可證但實際檢出更多的許可證會導(dǎo)致RMS中的可用計數(shù)少于LM中實際可用許可證計數(shù)，導(dǎo)致提前調(diào)度作業(yè)運(yùn)行并失敗。

(3)殘留用戶進(jìn)程占用許可證。在系統(tǒng)故障等條件下，可能出現(xiàn)作業(yè)運(yùn)行結(jié)束，但應(yīng)用軟件的進(jìn)程仍殘留在計算節(jié)點(diǎn)上的情況。這種情況下，進(jìn)程將仍占用寶貴的許可證資源，造成系統(tǒng)效率低下。在理想情況下，作業(yè)結(jié)束后應(yīng)強(qiáng)制其釋放分配的全部資源，包括程序檢出的許可證資源。這樣，即使有進(jìn)程殘留，其檢出的許可證也因失效而被回收。

(4)資源管理系統(tǒng)調(diào)度作業(yè)運(yùn)行與應(yīng)用軟件實際檢出許可證之間存在時間差。用戶的作業(yè)可能需要前處理等耗時操作，或者復(fù)雜軟件需要多種許可證，分別在不同時間段檢出。即便將輪詢LM與調(diào)度作業(yè)運(yùn)行的時間間隔縮得再小，也不能避免因此時間差導(dǎo)致的LM中實際可用許可證數(shù)目發(fā)生變化。

由于目前的許可證管理軟件在設(shè)計時未能考慮資源管理系統(tǒng)的存在和需求，現(xiàn)存的RMS和LM交互困難，給并行系統(tǒng)的運(yùn)行效率帶來負(fù)面效應(yīng)，導(dǎo)致用戶體驗下降。并行系統(tǒng)中需要一種新的模型來適應(yīng)具有RMS的作業(yè)運(yùn)行環(huán)境。

3 基于令牌的許可證管理模型

為解決查詢許可證數(shù)量與使用許可證的時間差產(chǎn)生競爭條件問題，本節(jié)提出一個適用于并行計算機(jī)系統(tǒng)的基于令牌的許可證管理模型(簡稱令牌模型)。其核心思想是將許可證的分配與使用分開，并且許可證的分配由RMS代理應(yīng)用軟件進(jìn)行，從而容許通過RMS對許可證資源進(jìn)行完全控制與調(diào)度。

3.1 令牌模型

基于令牌的許可證管理模型如圖2所示。在此模型中， LM負(fù)責(zé)對許可證使用的控制，而RMS負(fù)責(zé)許可證的調(diào)度分配。

Figure 2 Token-based license management model圖2 基于令牌的許可證管理模型

在令牌模型中，應(yīng)用軟件對許可證的使用被顯式地分成兩步：許可證資源分配與許可證檢出。其中，許可證資源分配可以由RMS代替應(yīng)用軟件進(jìn)行。典型的作業(yè)運(yùn)行并使用許可證的流程如下：

(1)用戶提交作業(yè)到RMS，注明作業(yè)的許可證資源需求；

(2)RMS在調(diào)度作業(yè)時，判斷許可證資源的可用性，并向LM申請使用許可證；

(3)LM向RMS返回一個令牌(token)，用于標(biāo)識所申請的許可證資源；

(4)RMS加載作業(yè)運(yùn)行時，將令牌傳遞給應(yīng)用軟件進(jìn)程；

(5)應(yīng)用軟件憑令牌從LM檢出許可證使用。

許可證的釋放也顯式地分為兩步。應(yīng)用進(jìn)程退出前或使用許可證結(jié)束后，向LM檢入所使用的許可證；作業(yè)運(yùn)行結(jié)束時RMS通知LM，LM使該令牌失效并強(qiáng)制回收許可證。這樣即使應(yīng)用進(jìn)程殘留，也不能繼續(xù)占用相應(yīng)的許可證。

3.2 RMS與LM交互接口

在令牌模型中，RMS與LM交互的主要接口包括：

(1)get_feature_count：獲取指定許可證特性的可用數(shù)目。

(2)allocate_feature：分配指定數(shù)目的許可證特性，如果分配成功，將返回一個令牌。

(3)return_feature：回收指定令牌對應(yīng)的許可證特性。

引入get_feature_count接口的目的是便于RMS向LM查詢當(dāng)前可用許可證數(shù)目。由于RMS進(jìn)行作業(yè)調(diào)度時需要多次判斷作業(yè)的許可證資源是否可用，一個低開銷的查詢接口可以避免因調(diào)用分配許可證接口引入的較大開銷而造成調(diào)度性能低下。

4 令牌模型的實現(xiàn)方法

在一個新的LM中實現(xiàn)令牌模型及與RMS的交互接口很直接。但現(xiàn)實中存在大量的遺留應(yīng)用軟件，它們所采用的許可證管理方式并不是基于令牌模型設(shè)計的。一個好的許可證管理模型需要充分考慮現(xiàn)存遺留軟件，支持現(xiàn)有的LM尤其是FNP，才具有現(xiàn)實可行性。本節(jié)探討在現(xiàn)有廣泛使用的許可證管理軟件上實現(xiàn)令牌管理模型的方法。從第3節(jié)的介紹可知，實現(xiàn)的關(guān)鍵在于限制許可證的非分配使用。

4.1 基于預(yù)留的機(jī)制

FNP支持對軟件許可證進(jìn)行預(yù)留[7]，通過修改許可證文件以及第三方軟件供應(yīng)商配置文件，可以將指定數(shù)量的許可證特性預(yù)留給指定的用戶、用戶組、主機(jī)或者項目?；诖丝梢詫崿F(xiàn)上述的令牌模型。在此實現(xiàn)方式中，作業(yè)、RMS及LM的交互流程如下：

(1)在FNP許可配置文件中，為供應(yīng)商守護(hù)進(jìn)程設(shè)置配置文件。

(2)RMS初始化時，通過修改供應(yīng)商配置文件，預(yù)留全部許可證給root用戶以及項目RMS。將許可證全部預(yù)留給root用戶實際上實現(xiàn)了對非分配許可證使用的限制。

(3)get_feature_count接口：lmutil命令的包裝，通過解析lmutil命令的輸出獲得可用許可證數(shù)目。

(4)allocate_feature接口：編輯供應(yīng)商配置文件，將所請求數(shù)目的許可證從預(yù)留給root用戶和項目RMS轉(zhuǎn)為預(yù)留給提交作業(yè)的用戶和項目RMS_JOB_jobid，其中jobid為作業(yè)在RMS中的標(biāo)識；然后指示FNP管理守護(hù)進(jìn)程重讀配置文件。

(5)RMS加載作業(yè)運(yùn)行時，為應(yīng)用程序設(shè)置環(huán)境變量LM_PROJECT=RMS_JOB_jobid，以指示應(yīng)用軟件以該項目使用許可證。

(6)return_feature接口:編輯供應(yīng)商配置文件，將為作業(yè)用戶和項目所預(yù)留的許可證轉(zhuǎn)為為root用戶和項目RMS預(yù)留；然后指示FNP管理守護(hù)進(jìn)程重讀配置文件。

在此實現(xiàn)機(jī)制中，許可證令牌即是作業(yè)的用戶身份以及FNP項目RMS_JOB_jobid。雖然項目名字未加密，但由于FNP會限制檢出許可證的用戶，因此其它用戶無法通過偽造項目名字而竊取使用許可證。此機(jī)制的另一個問題是，需要避免其它用戶或軟件對供應(yīng)商配置文件的編輯，以免引發(fā)沖突和競爭。由于管理員可以限制只有root用戶才能編輯供應(yīng)商配置文件，這種沖突可以通過協(xié)調(diào)管理員的行為避免。

4.2 基于代理的機(jī)制

并非所有的LM均支持對許可證的預(yù)留。本文設(shè)計的另一種在遺留應(yīng)用和LM上實現(xiàn)令牌模型的方法是，通過控制應(yīng)用軟件與LM之間的通信來控制對許可證的使用。在此機(jī)制中設(shè)計了兩個代理軟件：LM Proxy和App Proxy，來完成對應(yīng)用軟件與LM之間通信的控制。此實現(xiàn)機(jī)制如圖3所示。

Figure 3 Implementation mechanism based on proxy圖3 基于代理的實現(xiàn)機(jī)制

在基于代理的實現(xiàn)機(jī)制中，RMS不與LM直接進(jìn)行交互，而是通過LM Proxy和App Proxy完成對許可證資源的使用控制。實現(xiàn)要點(diǎn)如下：

(1)所有應(yīng)用軟件與LM的通信都必須經(jīng)過LM Proxy的許可才能進(jìn)行。這可以通過控制LM所運(yùn)行的節(jié)點(diǎn)上的防火墻規(guī)則，或者由LM Proxy轉(zhuǎn)發(fā)所有到LM的通信報文來完成。

(2)許可證的分配與調(diào)度在RMS內(nèi)部進(jìn)行。RMS生成一個加密串作為許可證令牌。在分配或釋放許可證資源之后，RMS將分配或釋放信息傳遞給LM Proxy。

(3)在加載應(yīng)用進(jìn)程運(yùn)行時，RMS將為作業(yè)分配的許可證令牌傳遞給App Proxy。App Proxy與應(yīng)用進(jìn)程運(yùn)行在相同的計算節(jié)點(diǎn)上；對于并行應(yīng)用軟件，如有必要可以在運(yùn)行應(yīng)用軟件進(jìn)程的每個節(jié)點(diǎn)上都運(yùn)行相應(yīng)的App Proxy。

(4)當(dāng)應(yīng)用進(jìn)程需要檢出許可證時，其與LM的通信連接將被App Proxy截獲,這可以通過對應(yīng)用程序外掛鉤子函數(shù)實現(xiàn)。App Proxy將首先與LM Proxy進(jìn)行通信，發(fā)送應(yīng)用軟件需要使用的許可證信息，包括所需特性及數(shù)量，以及相應(yīng)的令牌。LM Proxy根據(jù)許可證分配信息以及App Proxy發(fā)送的信息，決定是否允許應(yīng)用進(jìn)程與LM之間的通信。

(5)許可證資源被RMS回收之后，相關(guān)信息被傳遞到LM Proxy，對應(yīng)的許可證令牌不再有效，且原有應(yīng)用進(jìn)程與LM的通信被切斷，以避免殘留應(yīng)用進(jìn)程對許可證資源的占用。

在此實現(xiàn)機(jī)制中，關(guān)鍵的挑戰(zhàn)是App Proxy能夠獲得應(yīng)用軟件要使用的許可證特性以及數(shù)量。由于應(yīng)用軟件與LM的通信都是加密的，從其通信報文中解析出相關(guān)信息是不現(xiàn)實的。一般而言，應(yīng)用軟件的行為可以從其運(yùn)行參數(shù)、輸入條件等確定。因此，可以在軟件運(yùn)行時記錄LM端的日志并進(jìn)行分析，獲得應(yīng)用軟件對許可證的使用規(guī)律，形成一種規(guī)則庫。App Proxy可以結(jié)合作業(yè)并行規(guī)模等RMS所提供的作業(yè)信息，結(jié)合此規(guī)則庫，確定作業(yè)對許可證的需求信息。

5 結(jié)束語

軟件許可證作為一種昂貴的資源需要進(jìn)行合理的調(diào)度管理以提高資源利用率。本文提出的基于令牌的許可證管理模型可以有效地解決現(xiàn)在的許可證管理軟件與并行計算機(jī)資源管理系統(tǒng)的結(jié)合問題，避免因許可證資源分配與應(yīng)用軟件實際檢出之間的時間差產(chǎn)生的競爭條件導(dǎo)致作業(yè)運(yùn)行失敗問題，提升并行計算機(jī)系統(tǒng)的用戶使用體驗和資源利用率。下一步將對不同種類資源的調(diào)度分配次序以及不同的調(diào)度策略對系統(tǒng)性能的影響展開研究。

[1] Flexera Software.FlexNet licensing[EB/OL].[2013-09-25].http://www.flexerasoftware.com/products/entitlement-management/flexnet-licensing/.

[2] Reprise software[EB/OL].[2013-09-25].http://www.reprisesoftware.com/index.php.

[3] Safenet Inc. Sentinel RMS[EB/OL].[2013-09-25].http://www.safenet-inc.com/software-monetization/sentinel-rms/.

[4] Yoo A, Jette M, Grondona M. SLURM:Simple Linux utility for resource management[C]∥Proc of JSSPP’03, 2003:44-60.

[5] Platform. Managing software licenses with LSF[EB/OL].[2013-09-25].http://www.ccs.miami.edu/hpc/lsf/7.0.6/admin/licensemgt.html.

[6] Brophy B. SLURM license management[EB/OL].[2013-09-25].http://SLURM User Group Meeting.

[7] Acresso Software. FLEXnet publisher licensing toolkit 11.7:License administration guide[M]. US:Acresso Software Inc,2009.

CAO Hong-jia,born in 1977,PhD,associate research fellow,his research interests include resource management, and system software.

盧宇彤(1969-),女,湖南長沙人，博士，教授，博士生導(dǎo)師，CCF會員(E200034926M)，研究方向為高性能計算，容錯計算，系統(tǒng)軟件。E-mail:ytlu@nudt.edu.cn

CAO Hong-jia,born in 1969,PhD,professor,PhD supervisor,CCF member(E200034926M)，her research interests include high performance computing，fault tolerant computing, and system software.

Token-based license management in parallel computer systems

CAO Hong-jia1,LU Yu-tong1,2
(1.College of Computer,National University of Defense Technology，Changsha 410073;2.State Key Laboratory of High Performance Computing,National University of Defense Technology，Changsha 410073,China)

A token-based license management model is proposed for parallel computer systems. In this model, license using is separated into two steps: license allocation and license check-out, namely. Accordingly license release is separated into check-in and return. License allocation and return may be performed by the resource management system for the application software. Under this model, the use of licenses is controlled by the resource management system totally, avoiding conditions such as license check-out out of resource management system, wrong number of licenses specified for jobs, and application process hang, which results in job failures and resource wasting. Two implementation mechanisms mapping this token-based model to currently popular application environment are designed for legacy applications and license managers, which show the feasibility and significance of the model.

resource management;job scheduling;license management;token

2013-10-05;

2013-12-15

國家自然科學(xué)基金資助項目(61120106005)；國家863計劃資助項目(2012AA01A301)

1007-130X(2014)03-0388-05

TP311

A

10.3969/j.issn.1007-130X.2014.03.002

曹宏嘉(1977-),男,博士，副研究員,研究方向為資源管理和系統(tǒng)軟件。E-mail:hjcao@nudt.edu.cn

通信地址：410073 湖南省長沙市國防科學(xué)技術(shù)大學(xué)計算機(jī)學(xué)院

Address:College of Computer,National University of Defense Technology，Changsha 410073,Hunan,P.R.China