基于客戶機分布式服務(wù)器系統(tǒng)模型的rpc通信設(shè)計

基于客戶機分布式服務(wù)器系統(tǒng)模型的rpc通信設(shè)計

1客戶機/分布式服務(wù)器模型的rpc通信rc是遠(yuǎn)程處理調(diào)用，是一種特定于不同計算機之間通信格式的協(xié)議。允許特定計算以執(zhí)行本地進(jìn)程一樣調(diào)用另一臺計算機的遠(yuǎn)程過程。開發(fā)人員可以將解決問題的傳統(tǒng)程序劃分為幾個或多個計算機。這些程序片段可以在兩個或更多的計算機上運行。當(dāng)程序片段運行另一個計算機的另一個端口映射器（機器的著名端口化器111）時，它會接收需要訪問的程序段的端口數(shù)，并將其接收。為了解決消息格式、傳輸和身份驗證不取決于特定應(yīng)用程序和服務(wù)，而是為客戶端服務(wù)器模型提供基礎(chǔ)。epc協(xié)議有幾種不同的實現(xiàn)，如sunrpc、apollorcc、oncrc等。本文主要以linux系統(tǒng)的開放網(wǎng)絡(luò)計算遠(yuǎn)程過程調(diào)用為cmpc（開放網(wǎng)絡(luò)感知調(diào)用）。現(xiàn)有的客戶/服務(wù)器模型已經(jīng)比較成熟,但是這種模型不能完成服務(wù)器的動態(tài)定位和服務(wù)的負(fù)載均衡,于是我們提出了客戶機/分布式服務(wù)器系統(tǒng)模型.該模型的RPC通信與客戶/服務(wù)器模型的RPC通信相比需要解決一些新的問題,本文提出了解決這些問題的方案和相關(guān)機制.2客戶機/分布式服務(wù)器系統(tǒng)模型現(xiàn)有的客戶/服務(wù)器模型中,客戶向指定的服務(wù)器發(fā)出請求,服務(wù)器處理請求后將處理結(jié)果返回給客戶.這種模型已應(yīng)用在大多數(shù)的網(wǎng)絡(luò)系統(tǒng)中,但這也給系統(tǒng)帶來了一些不便,如此時被請求的服務(wù)器已相當(dāng)繁忙,客戶可能會等待很長一段時間才能得到返回結(jié)果.更糟的情況是如被請求的服務(wù)器已經(jīng)崩潰,則客戶的請求會根本無法處理,而此時的網(wǎng)絡(luò)系統(tǒng)中也許還有很多可以為客戶提供服務(wù)的服務(wù)器存在.為了更有效的利用系統(tǒng)資源,也為了將來分布式網(wǎng)絡(luò)的發(fā)展和完善,這里提出了客戶機/分布式服務(wù)器系統(tǒng)模型,其示意圖如圖1所示.圖1中,客戶機原向服務(wù)器i發(fā)出請求,但此時服務(wù)器j很忙或已崩潰,則分布式服務(wù)器系統(tǒng)在能提供客戶機所要求服務(wù)的服務(wù)器中找到一臺此時系統(tǒng)負(fù)荷最小的服務(wù)器(如服務(wù)器j),服務(wù)器j處理完客戶機的請求后將結(jié)果返回給客戶機.3在客戶端網(wǎng)絡(luò)模型中，rc通信問題應(yīng)解決3.1解封事務(wù)處理號客戶/服務(wù)器模型中RPC通信的客戶和服務(wù)器之間交互關(guān)系如圖2所示.雙方各自的操作流程如圖中的標(biāo)號1到10所示.圖2中,操作1是指裝配參數(shù),產(chǎn)生RPC事務(wù)處理號,設(shè)置應(yīng)答定時器;操作2是指解封參數(shù),要注意的是匹配RPC事務(wù)處理號;操作3是指封裝結(jié)果,設(shè)置應(yīng)答響應(yīng)定時器;操作4是指解封結(jié)果,并發(fā)應(yīng)答.上述的RPC調(diào)用中服務(wù)器是由客戶方指定的,也就是說客戶方在決定進(jìn)行RPC調(diào)用之前必須知道所要調(diào)用的服務(wù)在哪臺服務(wù)器上,否則無法發(fā)起請求.即便在客戶指定了服務(wù)器之后,它所指定的服務(wù)器也可能正處于繁忙狀態(tài),無法立即滿足客戶機的請求,甚至處于崩潰狀態(tài),無法為客戶機提供服務(wù),這時客戶機的請求將無法得到滿足.3.2客戶機/服務(wù)器的rpc通信rpc造成客戶/服務(wù)器模型中的RPC通信的在服務(wù)器方響應(yīng)緩慢或根本無法響應(yīng)的情況下束手無策的原因是這種模型中RPC調(diào)用的開始就靜態(tài)指定了服務(wù)器的IP地址.客戶機在找到指定服務(wù)器上服務(wù)所在的端口后就將客戶機的IP地址、端口號、SOCKET號和指定的服務(wù)器的IP地址、端口號和SOCKET號建立了一個全連接.在連接失敗的情況下這個連接就被銷毀,從而無法動態(tài)調(diào)度另一臺能提供服務(wù)的服務(wù)器.客戶機/服務(wù)器系統(tǒng)中RPC通信的設(shè)計要解決的問題就是將建立全連接的時間推遲到確認(rèn)最終向客戶機提供服務(wù)的服務(wù)器負(fù)荷最小(或確實能提供客戶機所請求的服務(wù))之后,從而實現(xiàn)系統(tǒng)調(diào)度的自我調(diào)節(jié)和負(fù)荷的均衡,在多數(shù)服務(wù)器崩潰的情況下(最壞情況下即只剩一臺能提供服務(wù)的服務(wù)器能正常工作的情況下),服務(wù)器系統(tǒng)仍能為客戶提供服務(wù),從而滿足客戶機的請求.4rc通信設(shè)計4.1dr模式pc請求·在保留原來的建立RPC連接的函數(shù)(以下統(tǒng)一稱為clnt_create函數(shù))的條件下開發(fā)一個新的建立RPC連接的函數(shù)(以下被統(tǒng)一稱為D_clnt_create函數(shù)),保留clnt_create的原因是有可能某個客戶機對當(dāng)前分布式服務(wù)器系統(tǒng)的情況相當(dāng)熟悉,或者知道它所請求的服務(wù)僅在某臺服務(wù)器上有,此時它不想或不愿進(jìn)行系統(tǒng)的調(diào)度,那么clnt_create還是可以提供原來客戶/服務(wù)器模型下的RPC連接功能.D_clnt_create函數(shù)將RPC請求的參數(shù)(其中包括RPC請求的程序號、版本號和所用的協(xié)議)中程序號和版本號封裝在一個結(jié)構(gòu)中,先不進(jìn)行客戶機和服務(wù)器的RPC連接,而是通過服務(wù)器的端口映射器(portmapper)轉(zhuǎn)向執(zhí)行一個守護(hù)程序(以下稱為DR守護(hù)程序)進(jìn)行服務(wù)器的動態(tài)調(diào)度.其中封裝好的參數(shù)也被傳入到DR守護(hù)程序中.·DR守護(hù)程序的工作過程如下.DR守護(hù)程序?qū)_clnt_create函數(shù)傳入的參數(shù)(程序號和版本號)作為輸入?yún)?shù)向分布式服務(wù)器系統(tǒng)中各個服務(wù)器的端口映射器(portmapper)廣播請求執(zhí)行一個特定的取得該服務(wù)器負(fù)荷的過程(以下稱為getload過程),各服務(wù)器上的getload過程執(zhí)行后將各自的負(fù)荷返回給發(fā)起getload請求的端口映射器,各服務(wù)器的端口映射器再將各自的結(jié)果分別返回給發(fā)起廣播請求的服務(wù)器中的DR守護(hù)程序.接著DR守護(hù)程序收集響應(yīng)包,并從響應(yīng)的服務(wù)器中找出一個負(fù)荷最小的服務(wù)器,從該服務(wù)器中的響應(yīng)包中提取IP地址和端口號,并封裝在一個結(jié)構(gòu)中返回給D_clnt_create函數(shù).·D_clnt_create函數(shù)再根據(jù)客戶方請求參數(shù)中的所用協(xié)議這一參數(shù)進(jìn)行TCP/UDP連接,因為廣播是基于UDP之上的,由廣播響應(yīng)包發(fā)回的端口號是服務(wù)所在的UDP端口,所以這時如果要進(jìn)行的是UDP的連接,可直接利用廣播響應(yīng)包返回的目標(biāo)服務(wù)器的IP地址和端口號;如果這時要進(jìn)行的是TCP連接,則目標(biāo)服務(wù)器的IP地址可直接利用,而端口號不可利用,但這時仍可進(jìn)行正確的TCP連接,因為我們已經(jīng)在廣播響應(yīng)包中找到了此時分布式服務(wù)器系統(tǒng)中負(fù)荷最小的服務(wù)器的IP地址,接下來可以調(diào)用clnt_create來完成RPC通信的建立RPC連接的工作.4.2dr保護(hù)程序客戶機/分布式服務(wù)器系統(tǒng)中RPC通信的設(shè)計框圖如圖3所示.(為方便說明起見,圖3中是只由3臺服務(wù)器組成的分布式服務(wù)器系統(tǒng).)以下就設(shè)計框圖進(jìn)行說明(圖中的每個過程標(biāo)號在網(wǎng)絡(luò)傳輸上分別表現(xiàn)為一個數(shù)據(jù)包的傳遞):①過程1:客戶機中的D_clnt_create()將封裝好的要調(diào)用的服務(wù)程序的程序號和版本號作為傳輸參數(shù),向某臺服務(wù)器(這臺服務(wù)器的指定方法將在本部分的第(4)小節(jié)討論)的端口映射器查詢該臺服務(wù)器中DR守護(hù)程序所在的端口號.②過程2:服務(wù)器的端口映射器查到DR守護(hù)程序所在的端口號后將該端口號返回給客戶機中的D_clnt_create()函數(shù).③過程3:D_clnt_create()函數(shù)和服務(wù)器方的DR守護(hù)程序建立RPC連接.④過程4:DR守護(hù)程序向分布式服務(wù)器系統(tǒng)中所有服務(wù)器的端口映射器發(fā)廣播,請求調(diào)用各服務(wù)器方程序中的getload()過程.⑤過程5:收到廣播的各服務(wù)器方端口映射器調(diào)用服務(wù)器方程序中的getload()過程.⑥過程6:各服務(wù)器方程序?qū)etload()的執(zhí)行結(jié)果返回給端口映射器.⑦過程7:各端口映射器再將getload()的執(zhí)行結(jié)果發(fā)回給發(fā)起廣播請求的DR守護(hù)程序.⑧過程8:發(fā)起廣播請求的DR守護(hù)程序從返回應(yīng)答的各服務(wù)器選一臺目前負(fù)荷參數(shù)最小的服務(wù)器,將其IP地址和服務(wù)所在UDP端口號返回給客戶機的D_clnt_create()函數(shù).之后,客戶機的D_clnt_create()利用DR守護(hù)程序發(fā)回的IP地址和UDP端口號進(jìn)行和最終提供服務(wù)的服務(wù)器的連接.4.3服務(wù)器方應(yīng)用程序接口如上所述,引起DR守護(hù)程序選定最終提供服務(wù)的服務(wù)器的關(guān)鍵因素是各服務(wù)器應(yīng)用程序中的過程getload()返回的結(jié)果.getload()過程綜合評定當(dāng)前此過程所在服務(wù)程序的繁忙程度.將這樣一個過程放在應(yīng)用程序級的原因是因為只有應(yīng)用程序本身對自己目前提供此類服務(wù)的情況最為清楚.當(dāng)然這就對服務(wù)器方應(yīng)用程序提出了一定的要求,如應(yīng)用程序中必須要提供getload()這樣一個過程和在服務(wù)器方應(yīng)用程序的接口程序中要對getload()的接口進(jìn)行說明.這些問題可以通過通用函數(shù)的形式解決,即編寫通用函數(shù)放在函數(shù)庫中,服務(wù)器方應(yīng)用程序在執(zhí)行時對其進(jìn)行調(diào)用即可.4.4用戶配置文件設(shè)計這里討論的是客戶機的調(diào)度請求到了分布式服務(wù)器系統(tǒng)之后由哪臺服務(wù)器優(yōu)先執(zhí)行其守護(hù)程序,從而發(fā)廣播找出最優(yōu)的并最終提供客戶機服務(wù)的服務(wù)器的問題.這個問題可以有兩種解決方法.其一是在客戶機中做一靜態(tài)配置文件,這個配置文件指定了客戶機和分布式服務(wù)器系統(tǒng)通信時先聯(lián)系服務(wù)器系統(tǒng)中的哪臺服務(wù)器,考慮到有可能先聯(lián)系的服務(wù)器本身也可能崩潰或非常繁忙,所以配置文件中最少有兩臺優(yōu)先聯(lián)系的服務(wù)器的IP地址.客戶機的D_clnt_create()函數(shù)將從這個配置文件中找到它先請求服務(wù)器系統(tǒng)中的哪臺服務(wù)器進(jìn)行服務(wù)器的調(diào)度并選出最終為之提供服務(wù)的服務(wù)器.在實際應(yīng)用中可以做三級優(yōu)先請求服務(wù)器(即配置文件中有三個優(yōu)先向它們發(fā)出請求的服務(wù)器的IP地址).這種設(shè)計和實現(xiàn)方法都比較簡單也比較有效.但是配置文件中指定的服務(wù)器不能自動改變,即如果管理員不對其進(jìn)行手動更改,它的內(nèi)容將保持不變.另一種實現(xiàn)方法是做動態(tài)配置文件,這個動態(tài)配置文件反映了分布式服務(wù)器系統(tǒng)中各個服務(wù)器的當(dāng)前狀況,某個時刻按照某種策略對各個服務(wù)器的使用情況進(jìn)行評估,找到當(dāng)前情況下性能最優(yōu)的三臺服務(wù)器,將它們的IP地址寫在某個配置文件中傳送給各個客戶機.一段時間后重新評估各服務(wù)器性能,再重新傳送給各個客戶機.這種方法較第一種設(shè)計方法困難和復(fù)雜的多.其中要考慮的問題也很多,如選用哪種策略對服務(wù)器進(jìn)行評估、隔多長時間評估一次等.因為這種方法還要在分布式服務(wù)器系統(tǒng)和客戶機之間傳送動態(tài)配置文件,所以系統(tǒng)的開銷也會大大增加.4.5重要的要素和解決4.5.1客戶機至服務(wù)器dr攻擊程序要得到充分的返還這里所說的超時首先是客戶機的超時,主要指的是客戶機在未得到來自服務(wù)器DR守護(hù)程序響應(yīng)的情況下等待的最長時間.需注意的是客戶機的超時不能小于服務(wù)器DR守護(hù)程序的超時,否則客戶機在DR守護(hù)程序未完成之前就會返回,從而無法得到正確的結(jié)果;其次是服務(wù)器DR守護(hù)程序的超時,主要指的是服務(wù)器DR守護(hù)程序在未得到來自各個服務(wù)器方應(yīng)用程序響應(yīng)的情況下等待的最長時間.需注意的是服務(wù)器DR守護(hù)程序的超時不能小于各個服務(wù)器方應(yīng)用程序的最大的超時.還有一點是服務(wù)器DR守護(hù)程序中要完成廣播包的發(fā)送和接收,如果廣播包的超時設(shè)的過長,則在沒有任何服務(wù)器響應(yīng)的情況下客戶方會等待相當(dāng)長的一段時間;如果設(shè)的過短,則有些廣播響應(yīng)包可能還未來得及接收到,在局域網(wǎng)的條件下,3秒的廣播超時已經(jīng)足夠.4.5.2廣播響應(yīng)包測試在成功發(fā)送廣播包的情況下,即使沒有任何響應(yīng)包返回,也不應(yīng)該再發(fā)廣播包了,因為此時可能系統(tǒng)中確實沒有能提供所要求的服務(wù)的服務(wù)器存在.發(fā)送廣播包的次數(shù)過多會影響系統(tǒng)的性能,因為每個廣播包的發(fā)送都會引起接收者的相應(yīng)處理.客戶機在向配置文件中的某個服務(wù)器發(fā)出了調(diào)度請求之后,如果該臺服務(wù)器已經(jīng)成功的發(fā)送了廣播包,但未接收到廣播響應(yīng)包,客戶端應(yīng)當(dāng)認(rèn)定是服務(wù)器系統(tǒng)中當(dāng)前無可用的服務(wù)器存在,而不是繼續(xù)向配置文件的下一臺服務(wù)器提出調(diào)度請求.客戶機僅在服務(wù)器未能成功的發(fā)送廣播請求的情況下才去向配置文件中的下一臺服務(wù)器提出調(diào)度請求.4.5.3dr函數(shù)本文所討論客戶機/分布式服務(wù)器系統(tǒng)中的DR守護(hù)程序的尋址遵循RPC的尋址方式,它也是用程序號、版本號和協(xié)議號來標(biāo)識的,客戶機中的D_clnt_create()函數(shù)