專利名稱：輕型輸入/輸出協(xié)議的制作方法
技術(shù)領(lǐng)域：
本發(fā)明一般涉及遠(yuǎn)程文件訪問的系統(tǒng)和方法，尤其涉及使用遠(yuǎn)程直接存儲(chǔ)
器存取(RDMA)來下傳(offload)輸入/輸出處理的技術(shù)。
背景技術(shù)：
在計(jì)算環(huán)境中通常希望節(jié)省寶貴的CPU資源。對(duì)如應(yīng)用程序服務(wù)器節(jié)點(diǎn)的 網(wǎng)絡(luò)那樣的環(huán)境，那樣的節(jié)省是尤其至關(guān)重要的。當(dāng)網(wǎng)絡(luò)變得更快時(shí)，它們對(duì) CPU提出更高要求來處理包并完成I/O操作，這導(dǎo)致更慢的應(yīng)用程序性能。對(duì) 于如數(shù)據(jù)庫那樣固有地1/0密集型應(yīng)用程序這特別不利。
補(bǔ)救這一問題的一種方法是從CPU中下傳過多的1/0和網(wǎng)絡(luò)處理。在聯(lián)網(wǎng) 環(huán)境中，使用分布式文件系統(tǒng)和注入NFS或SMB/CIFS等傳輸協(xié)議，可能將I/O 請(qǐng)求從本地機(jī)器發(fā)送到遠(yuǎn)程機(jī)器。然而，情況不必是本地機(jī)器使用這類方法能 夠達(dá)到顯著的處理節(jié)省。
在單機(jī)情況下，通過將I/O任務(wù)下傳到直接存儲(chǔ)器存取(DMA)控制器， I/O處理的負(fù)擔(dān)減輕了。遠(yuǎn)程直接存儲(chǔ)器存取(RMA)技術(shù)是用于多臺(tái)連網(wǎng)計(jì) 算機(jī)的最近發(fā)展的DMA擴(kuò)展。RDMA使數(shù)據(jù)能在裝有能夠進(jìn)行RDMA網(wǎng)絡(luò)接口卡 (NIC)的兩臺(tái)通信機(jī)器上的存儲(chǔ)緩存器之間傳送，而不必涉及源和目標(biāo)機(jī)器 雙方的CPU和操作系統(tǒng)。能使用RDMA將I/O處理下傳到遠(yuǎn)程機(jī)器，使本地機(jī) 器能重新要求CPU周期用于應(yīng)用程序。RDMA已被用于高速、高帶寬互連技術(shù)， 如虛擬接口體系結(jié)構(gòu)(VIA) 、 InfiniBand和iWarp。這些互連特別為在數(shù)據(jù) 中心或其它本地文件共享環(huán)境中服務(wù)器節(jié)點(diǎn)的集群之間的高可靠性網(wǎng)絡(luò)連接 而設(shè)計(jì)。
為了充分利用與RDMA技術(shù)關(guān)聯(lián)的能力并有效地得到其好處，必須設(shè)計(jì)定 義在本地下傳節(jié)點(diǎn)和遠(yuǎn)程機(jī)器之間通信的協(xié)議。因此需要本發(fā)明的輕型輸入/ 輸出(LWIO)協(xié)議。

發(fā)明內(nèi)容
按本發(fā)明的一方面，提供將1/0任務(wù)從第一計(jì)算機(jī)下傳到第二計(jì)算機(jī)的系 統(tǒng)。該系統(tǒng)包括在第一計(jì)算機(jī)上運(yùn)行的客戶機(jī)和在第二計(jì)算機(jī)上運(yùn)行的服務(wù)器
程序。該系統(tǒng)還包括鏈接第一計(jì)算機(jī)和第二計(jì)算機(jī)的一個(gè)或多個(gè)RDMA通道。 客戶機(jī)和服務(wù)器程序按照包括網(wǎng)絡(luò)發(fā)現(xiàn)階段和I/O處理階段的LWIO協(xié)議通信。 結(jié)合如SMB/CIFS等另外網(wǎng)絡(luò)協(xié)議使用LWIO協(xié)議，充分調(diào)動(dòng)了第二協(xié)議的安全 性和認(rèn)證的基礎(chǔ)結(jié)構(gòu)。為提供更好的安全模型，協(xié)議中的1/0模型是非對(duì)稱的 讀使用RDMA來實(shí)現(xiàn)，而寫使用發(fā)送操作來實(shí)現(xiàn)。
按照本發(fā)明的另一方面，提供將1/0任務(wù)從第一計(jì)算機(jī)下傳到第二計(jì)算機(jī) 的方法。該方法利用兩臺(tái)計(jì)算上共同的能進(jìn)行RDMA的通信設(shè)備，并與輕型輸 入/輸出(LWIO)客戶機(jī)一服務(wù)器協(xié)議關(guān)聯(lián)。協(xié)議通常包括發(fā)現(xiàn)階段及隨后的 1/0處理階段。在發(fā)現(xiàn)階段，客戶機(jī)和服務(wù)器確定共享的能進(jìn)行RDMA的提供者 的最小列表。在I/0處理階段，客戶機(jī)發(fā)送I/0請(qǐng)求以便下傳到第二機(jī)器。
在發(fā)現(xiàn)階段，客戶機(jī)最初從服務(wù)器器獲得服務(wù)器請(qǐng)求繼續(xù)鍵(resurae key)。 客戶機(jī)隨后打開通向服務(wù)器的管道，客戶機(jī)通過此管道發(fā)送包含第一機(jī)器上能 進(jìn)行RDMA的提供者列表的協(xié)商請(qǐng)求。服務(wù)器通過該管道發(fā)送包含第二機(jī)器上 匹配第一機(jī)器上的提供者的可用提供者的列表的協(xié)商響應(yīng)。然后客戶機(jī)創(chuàng)建通 過共享的提供者到服務(wù)器的RDMA連接?？蛻魴C(jī)及服務(wù)器互相認(rèn)證新的連接。
客戶機(jī)然后注冊(cè)一個(gè)或多個(gè)文件為服務(wù)器使用。
I/O處理請(qǐng)求消息包括關(guān)閉消息、取消消息、讀消息、寫消息、向量化讀 消息、以及向量化寫消息。為安全原因，協(xié)議表現(xiàn)非對(duì)稱VO模型。讀數(shù)據(jù)使 用RDMA寫操作被發(fā)送到客戶機(jī)，而寫使用常規(guī)的發(fā)送來完成。由客戶機(jī)指定 讀和寫請(qǐng)求，讓服務(wù)器以輪詢模式或中斷模式完成。若客戶機(jī)表示，不應(yīng)以輪 詢模式完成，則服務(wù)器借助通過RDMA傳輸發(fā)送狀態(tài)塊到第一計(jì)算機(jī)來完成I/O 處理請(qǐng)求。若客戶機(jī)表示應(yīng)該以輪詢模式完成，則客戶機(jī)可請(qǐng)求在完成1/0之 后服務(wù)器通過中斷請(qǐng)求消息來喚醒它。
按本發(fā)明的另外方面，提供以1/0下傳協(xié)議管理緩存器的方法。該方法涉 及使用緩存器信用點(diǎn)(credit)機(jī)制。服務(wù)器一客戶機(jī)信用點(diǎn)事務(wù)包括由服務(wù) 器發(fā)動(dòng)并完成的三路握手。服務(wù)器發(fā)送一增量信用點(diǎn)消息給客戶機(jī)，包括設(shè)置 成信用點(diǎn)數(shù)的信息字段。若該數(shù)為負(fù)數(shù)-N，則客戶機(jī)必須放棄N個(gè)信用點(diǎn)。
本發(fā)明的另外方面包括作為計(jì)算機(jī)程序產(chǎn)品及數(shù)據(jù)結(jié)構(gòu)體現(xiàn)在計(jì)算機(jī)可 讀介質(zhì)的上述特征。


雖然附后的權(quán)利要求以細(xì)節(jié)列出了本發(fā)明的特征，從下面結(jié)合附圖的詳細(xì) 描述能更好地理解本發(fā)明及其目標(biāo)和優(yōu)點(diǎn)，附圖中
圖1是一般示出示例性客戶機(jī)一服務(wù)器計(jì)算環(huán)境的原理圖，它包括兩臺(tái)能 通過RDMA傳輸通信的計(jì)算機(jī)，該環(huán)境能加入本發(fā)明的各方面；
圖2是按本發(fā)明的實(shí)施例一般示出的在LWIO協(xié)議的發(fā)現(xiàn)階段中采取的初 始步驟的流程圖3是按本發(fā)明的實(shí)施例一般示出示例性服務(wù)器請(qǐng)求繼續(xù)鍵的表示的概略
圖4A是按本發(fā)明的實(shí)施例一般示出示例性客戶機(jī)協(xié)商請(qǐng)求消息的表示的 概略圖4B是按本發(fā)明的實(shí)施例一般示出示例性服務(wù)器協(xié)商響應(yīng)的表示的概略
圖5是按本發(fā)明的實(shí)施例一般示出在LWIO協(xié)議的發(fā)現(xiàn)階段采取的附加步 驟的流程圖6A是按本發(fā)明的實(shí)施例一般示出示例性客戶機(jī)認(rèn)證請(qǐng)求消息的表示的 概略圖6B是按本發(fā)明的實(shí)施例一般示出示例性服務(wù)器認(rèn)證響應(yīng)的表示的概略
圖6C是按本發(fā)明的實(shí)施例一般示出完成認(rèn)證的示例性服務(wù)器狀態(tài)響應(yīng)的 表示的概略圖7A是按本發(fā)明的實(shí)施例一般示出示例性客戶機(jī)注冊(cè)文件消息的表示的 概略圖7B是按本發(fā)明的實(shí)施例一般示出完成文件注冊(cè)的示例性服務(wù)器狀態(tài)響 應(yīng)的表示的概略圖8是按本發(fā)明的實(shí)施例一般示出對(duì)于以輪詢模式和以非輪詢模式完成 I/O請(qǐng)求采取的步驟的流程圖9A是按本發(fā)明的實(shí)施例一般示出示例性客戶機(jī)中斷請(qǐng)求消息的表示的 概略圖9B是按本發(fā)明的實(shí)施例一般示出完成中斷請(qǐng)求的示例性服務(wù)器狀態(tài)響
應(yīng)的表示的概略圖10是按本發(fā)明的實(shí)施例一般表示關(guān)于服務(wù)器一客戶機(jī)信用點(diǎn)事務(wù)采取 的步驟的流程圖IIA是按本發(fā)明的實(shí)施例一般表示示例性服務(wù)器增量信用點(diǎn)消息的表示 的概略圖IIB是按本發(fā)明的實(shí)施例一般表示示例性客戶機(jī)一服務(wù)器信用點(diǎn)消息的 表示的概略圖iic是按本發(fā)明的實(shí)施例一般表示完成客戶機(jī)一服務(wù)器信用點(diǎn)事務(wù)的示
例性服務(wù)器狀態(tài)響應(yīng)的表示的概圖12A是按本發(fā)明的實(shí)施例一般示出示例性客戶機(jī)關(guān)閉請(qǐng)求消息的表示的 概略圖12B是按本發(fā)明的實(shí)施例一般示出完成關(guān)閉請(qǐng)求的示例性服務(wù)器狀態(tài)響 應(yīng)的表示的概略圖13A是按本發(fā)明的實(shí)施例一般示出示例性客戶機(jī)取消請(qǐng)求消息的表示的 概略圖13B是按本發(fā)明的實(shí)施例一般表示完成取消請(qǐng)求的示例性服務(wù)器狀態(tài)響 應(yīng)的表示的概略圖14A是按本發(fā)明的實(shí)施例一般示出在非輪詢模式情況下的示例性客戶機(jī)
讀請(qǐng)求消息的表示的概略圖14B是按本發(fā)明的實(shí)施例一般示出在非輪詢模式情況下完成讀請(qǐng)求的示 例性服務(wù)器狀態(tài)響應(yīng)的表示的概略圖14C是按本發(fā)明的實(shí)施例一般示出在輪詢模式情況下示例性客戶機(jī)讀請(qǐng) 求消息的表示的概略圖14D是按本發(fā)明的實(shí)施例一般示出在輪詢模式情況下完成讀請(qǐng)求的示例 性服務(wù)器1/0狀態(tài)塊的表示的概略圖15A是按本發(fā)明的實(shí)施例一般示出在非輪詢模式情況下示例性客戶機(jī)寫
請(qǐng)求消息的表示的概略圖15B是按本發(fā)明的實(shí)施例一般示出在非輪詢模式情況下完成寫請(qǐng)求的示 例性服務(wù)器狀態(tài)響應(yīng)的表示的概略圖15C是按本發(fā)明的實(shí)施例一般示出在輪詢模式情況下示例性客戶機(jī)寫請(qǐng) 求消息的表示的概略圖15D是按本發(fā)明的實(shí)施例一般示出在輪詢模式情況下完成寫請(qǐng)求的示例
性服務(wù)器1/0狀態(tài)塊的表示的概略圖16A是按本發(fā)明的實(shí)施例一般示出在非輪詢模式情況下示例性客戶機(jī)向量 化讀請(qǐng)求消息的表示的概略圖16B是按本發(fā)明的實(shí)施例一般示出在非輪詢模式情況下完成向量化讀請(qǐng)求 的示例性服務(wù)器狀態(tài)響應(yīng)的表示的概略圖16C是按本發(fā)明的實(shí)施例一般示出在輪詢模式情況下示例性客戶機(jī)向量化 讀請(qǐng)求消息的表示的概略圖16D是按本發(fā)明的實(shí)施例一般示出在輪詢模式情況下完成向量化讀請(qǐng)求的 示例性服務(wù)器I/O狀態(tài)塊的表示的概略圖17A是按本發(fā)明的實(shí)施例一般示出在非輪詢模式、非崩潰情況下示例性客 戶機(jī)向量化寫請(qǐng)求消息的表示的概略圖17B是按本發(fā)明的實(shí)施例一般示出在非輪詢模式、崩潰情況下示例性客戶 機(jī)向量化寫請(qǐng)求消息的表示的概略圖17C是按本發(fā)明的實(shí)施例一般示出在輪詢模式、崩潰情況下示例性客戶機(jī) 向量化寫請(qǐng)求消息的表示的概略圖17D是按本發(fā)明的實(shí)施例一般示例在非輪詢模式情況下完成向量化寫請(qǐng)求 的示例性服務(wù)器器狀態(tài)響應(yīng)的表示的概略圖；和
圖17E是按本發(fā)明的實(shí)施例一般示出在輪詢模式情況下完成向量化寫請(qǐng)求的 示例性服務(wù)器I/O狀態(tài)塊的表示的概略圖。
具體實(shí)施例方式
下面參考圖1 17E來討論本發(fā)明的某些實(shí)施例。然而本領(lǐng)域的技術(shù)人員容易 理解，這里給出的結(jié)合附圖的詳細(xì)描述是為說明目的，本發(fā)明超越這些實(shí)施例而延 伸。
圖1是一般示出在其中可加入本發(fā)明的各方面的代表性網(wǎng)絡(luò)化客戶機(jī)/服務(wù)器 環(huán)境的某些特征的原理圖。在圖l中畫出兩臺(tái)計(jì)算機(jī)，標(biāo)記為主機(jī)A101和主機(jī)B 121。雖然本發(fā)明可在包括許多不同類型和用途的計(jì)算機(jī)的環(huán)境中實(shí)施，然而在一 個(gè)代表性情況下，主機(jī)A 101起著如數(shù)據(jù)庫服務(wù)器等擔(dān)負(fù)I/O密集型工作的應(yīng)用程 序服務(wù)器的作用。
每個(gè)主機(jī)A IOI和主機(jī)B 121包括若干網(wǎng)絡(luò)接口卡(NIC) 109、 111、 113、133、 135、 137，允許從一個(gè)機(jī)器到另一機(jī)器的網(wǎng)絡(luò)化數(shù)據(jù)通信。在這些NIC中NIC 109、 111、 135、 137允許RDMA數(shù)據(jù)傳輸。如圖示，在兩主機(jī)101、 121之間給出 非RDMA網(wǎng)絡(luò)鏈路119和RDMA通道117。
在主機(jī)A 101上執(zhí)行的是LWIO客戶機(jī)應(yīng)用程序程序103，它與負(fù)責(zé)處理I/O 任務(wù)的應(yīng)用程序程序關(guān)聯(lián)，而I/0任務(wù)與核心模式I/0讀/寫服務(wù)器105交互。使 用LWIO客戶機(jī)103程序?qū)?/0處理從主機(jī)A 101下傳到主機(jī)B 121。在主機(jī)B 121 上執(zhí)行LWIO服務(wù)器123。按這里描述的LWIO協(xié)議，LWIO客戶機(jī)103與LWIO服務(wù) 器123通信。LWIO客戶機(jī)103和LWIO服務(wù)器123使用發(fā)送的緩存器107、 127，使 與文件關(guān)聯(lián)的數(shù)據(jù)借助RDMA通道連接117直接傳輸。借助LWIO協(xié)議消息，可將讀 和寫的任務(wù)下傳到主機(jī)B 121。服務(wù)器123將I/0請(qǐng)求傳送到文件系統(tǒng)129，后者 作為到硬盤131的接口。
通常，兩類消息與RDMA連接117相關(guān)。第一類是普通的網(wǎng)絡(luò)發(fā)送/接收，它 在目標(biāo)機(jī)器上生成一中斷。第二類是RDMA讀/寫，其中不需遠(yuǎn)程CPU的幫助來訪問 遠(yuǎn)程機(jī)器中的存儲(chǔ)空間，因此不必生成中斷。遠(yuǎn)程CPU確定為RDMA展現(xiàn)的存儲(chǔ)器 區(qū)域，但通常不知道何時(shí)完成RDMA操作。
在這里描述的本發(fā)明的實(shí)施例中，結(jié)合如SMB或CIFS等另一網(wǎng)絡(luò)協(xié)議使用 LWI0協(xié)議，以便利用其它協(xié)議的現(xiàn)有安全和認(rèn)證基礎(chǔ)結(jié)構(gòu)。這幫助最小化LWIO協(xié) 議的開銷。如圖1所示，主機(jī)B 121上的LWI0服務(wù)器123在SMB服務(wù)器125之上 操作。SMB客戶機(jī)(未示出)類似地在主機(jī)A 101上運(yùn)行，并與LWIO客戶機(jī)應(yīng)用 程序程序103交互。
LWIO協(xié)議包括兩個(gè)階段發(fā)現(xiàn)階段及隨后的1/0階段。與這里描述的實(shí)施例 相關(guān)的數(shù)據(jù)結(jié)構(gòu)、數(shù)據(jù)長度如下表示
BYTE無符號(hào)8位整數(shù)
CHAR8位ASCII碼字符
畫T16無符號(hào)16位整數(shù)
NINT32無符號(hào)32位整數(shù)
UINT64無符號(hào)64位整數(shù)
INT 16帶符號(hào)16位整數(shù)
INT32帶符號(hào)32位整數(shù)
INT64帶符號(hào)64位整數(shù)
WCHAR16位統(tǒng)一碼(Unicode)字符PV0ID32 32位指針
PV0ID64 64位指針
圖2示出在本發(fā)明的實(shí)施例中在LWIO協(xié)議的發(fā)現(xiàn)階段采取的步驟。對(duì)于在其 上執(zhí)行LWIO服務(wù)器的主機(jī)，在步驟201， LWIO服務(wù)器向在主機(jī)上運(yùn)行的SMB/CIFS 服務(wù)器注冊(cè)。按此注冊(cè)，在步驟203， SMB/CIFS服務(wù)器通知在LWIS服務(wù)器可用的 遠(yuǎn)程主機(jī)上運(yùn)行的SMB/CIFS客戶機(jī)。在步驟205， LWIO客戶機(jī)請(qǐng)求一服務(wù)器請(qǐng)求 繼續(xù)鍵。繼續(xù)鍵是一種認(rèn)證機(jī)制，它已在與本專利具有同一受讓人的另一專利中揭
示，該美國專利于2003年10月24日提交，序列號(hào):_，名為"Method and System
for Accessing a File (Resume KeY)(訪問文件的方法和系統(tǒng)(繼續(xù)鍵))"， 該專利通過引用整體結(jié)合于此。
在步驟207， LWIO服務(wù)器將服務(wù)器請(qǐng)求繼續(xù)鍵送回客戶機(jī)。在本發(fā)明的一實(shí)
施例中，服務(wù)器請(qǐng)求繼續(xù)鍵具有下列結(jié)構(gòu)
typedef struct —SRV—RESUME_KEY {
UINT64 ResumeKey/
UINT64 Timestamp/
UINT64 Pid; } SRV—RESUME—KEY, *PSRV—RESUME—KEY,.
typedef struct _SRV—REQUEST—RESUME—KEY {
SRV一RESUME二KEY— Ke^T; 一
UINfl6 一 ContextLength'.
BYTE Context [l],.
} SRV—REQUEST—RESUME—KEY, *PSRV—REQUEST—RESUME—KEY
圖3提供服務(wù)器請(qǐng)求繼續(xù)鍵219的圖示。在服務(wù)器上生成ResumeKey(繼續(xù)鍵)221、 Timestamp(時(shí)間標(biāo)記)223和Pid(進(jìn)程id)225，它們對(duì)客戶機(jī)是不透明的。Context
(上下文)229是包含由LWIO客戶機(jī)使用來聯(lián)系服務(wù)器的UNC名字的數(shù)組。 ContextLength (上下文長度)227是在Context 229中字節(jié)數(shù)。
網(wǎng)絡(luò)發(fā)現(xiàn)
當(dāng)客戶機(jī)應(yīng)用程序接收服務(wù)器請(qǐng)求繼續(xù)鍵219，它從Context字段229檢索服 務(wù)器UNC名字?；氐綀D2，在步驟209，客戶機(jī)打開通向LWIO服務(wù)器的管道。管道 用于以下述方式對(duì)在網(wǎng)絡(luò)上可用的能進(jìn)行RDMA的設(shè)備的自動(dòng)發(fā)現(xiàn)。這是本發(fā)明重 要且有用的特征；通常VIA網(wǎng)絡(luò)和類似網(wǎng)絡(luò)缺少如ARP等地址解析機(jī)制。
客戶機(jī)接著査詢服務(wù)器以尋找其可用于LWIO協(xié)議的能將進(jìn)行RDMA的設(shè)備 ("提供者")的列表。借助客戶機(jī)構(gòu)造并經(jīng)在步驟211新開的管道發(fā)送到服務(wù)器
的協(xié)商請(qǐng)求來完成查詢。在本發(fā)明的實(shí)施例中，協(xié)商請(qǐng)求有如下結(jié)構(gòu)
typedef struct {
LWIO—CONTROL—HEADER
WCHa5 _ ClientName [LWIO—max—HOST—NAME]
UUID Key,' — — —
UINT16 ResponseLength'-
UINT16 ProviderCount,'
LwioAddressBlk—t ProviderList [1],.
} LwioNegotiateRequest—t
typedef struct {
CHAR Protocolld[4]
UINT32 Revld,-
UINT16 Opcode,'
UINT16 Length,. } LWI〇—CONTROL—HEADER/
typedef struct —GUID {
UINT32 — Datal,-
UINT16 Data2'.
UINT16 Data3,.
BYTE Data4[8〗，' } GU工D, UUID,-
typedef struct { WCHAR UINT16
Name [LWIO一MAX一PROV工DER一NAME],. InstanceCount
LWIO—NET—ADDRESS InstanceTable [ 1 ] } LwioAddressBlk一t;
typedef struct —LWIO—NET—ADDRESS { UINT16 一 JTostAddressLen/ UINT16 DiscriminatorLen,-
BYTE HostAddressFollowedByDiscriminator [1]
} LW工0-NET一ADDRESS,'
圖4A提供在本發(fā)明實(shí)施例中的協(xié)商請(qǐng)求包231的圖示。協(xié)商請(qǐng)求包括控制首 部233、固定長度的統(tǒng)一代碼(Unicode)客戶機(jī)名字段235、用作密鑰的客戶機(jī) UUID 237、用于接收響應(yīng)的本地緩存器長度239、以及提供者列表241。在控制首 部233， ProtocolID (協(xié)議ID) 'LWIO， 243被儲(chǔ)存為首部的前4個(gè)字節(jié)。
Revld 245保存當(dāng)前定義的值0x1001、 LWI0一REV—ID。 Opcode (操作碼)247 保存當(dāng)前定義的值0xfe，LWI0—C0NTR0L_0PC0DE_NEG0TIATE。 Length (長度)249 是包括所有操作碼專用數(shù)據(jù)的擬發(fā)送給服務(wù)器的整個(gè)包的字節(jié)數(shù)。
服務(wù)器使用ClientName (客戶機(jī)名)235來標(biāo)識(shí)客戶機(jī)。如下所述，Key (密 鑰)237用于隨后的網(wǎng)絡(luò)專用認(rèn)證過程。如下所述，RespnoseLength (響應(yīng)長度)
239是用于從服務(wù)器接收協(xié)商響應(yīng)的緩存器長度。ProviderCount (提供者計(jì)數(shù)) 251是與客戶機(jī)相關(guān)聯(lián)并客戶機(jī)正通知的服務(wù)器的提供者者的數(shù)量。提供者者列表 241包含ProviderCount提供者的列表。
在提供者列表241的元素中，Name (名字)253是提供者的名。為了檢測(cè)兼容 網(wǎng)絡(luò)，客戶機(jī)和服務(wù)器最好對(duì)同一提供者使用同一名。InstanceCount (實(shí)例計(jì)數(shù)) 255是特定提供者類型的設(shè)備數(shù)，實(shí)例表257是網(wǎng)絡(luò)/鑒別器對(duì)的表，其中一對(duì)服 務(wù)器以設(shè)備專用方式描述如何形成遠(yuǎn)程連接。HostAddressLen (主機(jī)地址長度)259 是網(wǎng)絡(luò)專用主機(jī)地址263的長度。DiscriminatorLen (鑒別器長度)261是網(wǎng)絡(luò)專 用鑒別器265的長度。這些長度字段之后是主機(jī)地址263的HostAddressLen字節(jié) 和鑒別器265的DiscriminatorLen字節(jié)。
回到圖2，在接收到與提供者的客戶機(jī)列表的協(xié)商請(qǐng)求之后，在步驟213，服 務(wù)器確定它與客戶機(jī)具有哪些共同的能進(jìn)行RDMA通信的設(shè)備。在步驟215，服務(wù) 器經(jīng)該管道發(fā)送包括共享提供者列表的協(xié)商響應(yīng)到客戶機(jī)。在本發(fā)明的一個(gè)實(shí)施例
中，協(xié)商響應(yīng)具有如下結(jié)構(gòu)
typedef struct {
lwio—control—header;
WCHa5 — SrvName [lwio—max—host—n層E]
UUID Key/ — — —
UINT16 ProviderCount,'
LwioAddressBlk一t ProviderList [ 1 ] } LwioNegotiateResponse—t;
圖4B提供在本發(fā)明的實(shí)施例中協(xié)商響應(yīng)267的圖示。控制首部269與協(xié)商請(qǐng) 求的一樣，不同處是Length 271現(xiàn)在反映響應(yīng)消息267的長度。SrvName (服務(wù)器 名)273保存服務(wù)器的名。Key (關(guān)鍵字)275是服務(wù)器生成的GUID，為客戶機(jī)使 用。如下進(jìn)一步解釋，客戶機(jī)在認(rèn)證請(qǐng)求中通過使用一個(gè)共同通信設(shè)備的新連接將 Key送回給服務(wù)器。ProviderCount 277是在提供者列表中提供者的數(shù)量。提 供者列表279包含對(duì)服務(wù)器及客戶機(jī)共同的提供者的列表。不保證客戶機(jī)實(shí)際上能 連接到這些提供者。
回到圖2，此時(shí)服務(wù)器和客戶機(jī)共享通信設(shè)備信息，并已確定共同提供者的最 小列表。在步驟217，客戶機(jī)通過一個(gè)或多個(gè)共享設(shè)備創(chuàng)建一個(gè)或多個(gè)到LWI0服 務(wù)器的RDMA連接。在本發(fā)明的一個(gè)實(shí)施例中，如此處描述，對(duì)客戶機(jī)-服務(wù)器的通 信定義下列操作碼
#defineLWIO—_OPC〇DE-—READ0x0
#define:lwio_—opcode_—write0x1
#defineLWIO—_OPCODE_—VEC—READ0x2
弁define:lwi〇—_opcode__vec_write0x3
#defineLWIO一_OPCODE_—CLOSE0x4
#defineIiWIO_OPCODE——CANCEL0x5
#defineLWIO—_OPC〇DE_—AUTH0x6
#define!LWIO_—OPCODE_—REGISTER0x7
#defineLWIO——OPCODE——CREDIT0x8
#defineLWIOOPCODEINTERRUPT0x9
以下定義的標(biāo)志用作在客戶機(jī)-服務(wù)器通信中的修改符
#define LWIO—HDR—FLAG—INTERRUPT 0x80 #define LWIO—HDR_FLAG_C〇NTROL 0x4 0
#define LWIO—HDR—FLAG—COLLAPSE—IO 0x20
在LWIO協(xié)議的對(duì)應(yīng)客戶機(jī)-服務(wù)器消息表征一共同的首部結(jié)構(gòu)。在本發(fā)明的實(shí)施例
中，共同的首部具有以下格式-
typedef struct { UINT32 union { UINT32 struct {
BYTE
BYTE
BYTE
BYTE
struct { UINT16 UINT16 UINT32
UINT64
//數(shù)據(jù)緩存器塊 struct {'
PVOID64 union {
UINT32
struct {
UINT16 NumPages,.
Length,.
Status,'
Opcode; Flags,, Credits Marker;
Fid,.
Sequence; Tid'.
Offset;
DataMh,' <formula>formula see original document page 15</formula>連接認(rèn)證
圖5示出在本發(fā)明的實(shí)施例中在LWI0協(xié)議的初始階段余下部分由客戶機(jī)和服 務(wù)器采取的步驟。在步驟601，如上所述客戶機(jī)建立通過共享通信設(shè)備到服務(wù)器的 連接。現(xiàn)在客戶機(jī)和服務(wù)器互相認(rèn)證新的連接。在步驟603，客戶機(jī)發(fā)送認(rèn)證請(qǐng)求 消息(LWI0_0PC0DE_AUTH)到服務(wù)器。為防止服務(wù)器端和客戶機(jī)端免受欺騙而作認(rèn) 證。若認(rèn)證不能按時(shí)完成，連接終止。
圖6A提供在本發(fā)明的實(shí)施例中客戶機(jī)認(rèn)證請(qǐng)求消息的圖示。認(rèn)證消息617包 括共同首部619及隨后的LWI0_AUTH—PARAMS結(jié)構(gòu)621。在首部619中，Length 623 被設(shè)置成發(fā)送到服務(wù)器的字節(jié)數(shù)(共同首部619的長度加上LWIO—AUTH一PARAMS 621 的長度)。Opcode 被設(shè)為LWI0_0PC0DE—AUTH(0 X 6)。標(biāo)志627被設(shè)成 LWIO—HDR_FLAG_INTERRUPT。在這個(gè)和其它客戶機(jī)協(xié)議消息中，Cookie 629被設(shè)成 由客戶機(jī)選擇的值，并在服務(wù)器應(yīng)答中被送回。Cookie值通常被用于將請(qǐng)求與服 務(wù)器應(yīng)答匹配。DataVa 631被設(shè)成服務(wù)器應(yīng)當(dāng)對(duì)服務(wù)認(rèn)證參數(shù)進(jìn)行RDMA的地址。 DataMh 633保存與DataVa 631關(guān)聯(lián)的RDMA存儲(chǔ)器句柄。
在本發(fā)明的實(shí)施例中，LWI0_AUTH_PARAMS結(jié)構(gòu)具有如下格式#define LWIO一AUTH一OPTION一END #define LW工O二AUTH二OPT工O(KEY #define LWIO二AUTH二OPTION二SESSION—ID 弁define LWI〇=AUTH=0PT工ON二SiGNATu5e
#define LWIO—AUTH—OPTION—KEY—LENGTH
#define LW工0二AUTH二OPTION二SEs5lON—ID一LENGTH
弁define LWIO—AUTH—OPTION—SIGNATURE EeNGTH
2
3
16 8
typedef struct { UCHAR UCHAR BYTE
} LWIO AUTH OPTIONS,
OptionCode/ OptionLen/ OptionData [1] *LPLWI〇AUTH OPTIONS,
typedef struct { CHAR UINT16 UINT16 UINT16 UINT16 UINT32 UINT32 UINT32 UINT16 UINT16 UINT16
LWIO AUTH OPTIONS
Magic [4],- // 'LW工O' Rev工d,. Endian'. PageSize,. BaseSequence'. MaxRdmaWindowSize,-MaxSendBufferSize^ MaxRecvBuf f erSize'-HeaderSize'-Credits,'
RdmaReadSupported'. Options [1〗
} LWIO—AUTH_PARAMS, *LPLWI〇—AUTH—PARAMS;
在認(rèn)證消息617中，LWI0—AUTH—PA廳S 621構(gòu)成包的第二部分。Magic 635 設(shè)成'LWIO， 。 Revld 627設(shè)成LWI0—REV—ID。 Endian 639設(shè)成sizeof (UL0NG—PTR)。 PageSize 641設(shè)成CPU頁面大小(在32位機(jī)器上為4K，在64位機(jī)器上為8K)。 BaseSequence643設(shè)成0。 MaxRdmaWindowSize 6化試圖設(shè)成客戶機(jī)在一次RDMA傳 輸中可接受的最大字節(jié)數(shù)；在圖示的實(shí)施例中設(shè)成64K。 MaxSendBufferSize 647 試圖設(shè)成客戶機(jī)在單次請(qǐng)求中可向服務(wù)器發(fā)送的字節(jié)數(shù);在圖示的實(shí)施例中被設(shè)成 1K。 MaxRecvBufferSize 649試圖設(shè)成客戶機(jī)為了從服務(wù)器接收數(shù)據(jù)而發(fā)送的字節(jié) 數(shù)；在圖示的實(shí)施例中它被設(shè)成16字節(jié)。HeederSize 651被設(shè)成在LWI0控制首 部619中的字節(jié)數(shù)。Credits 652設(shè)成客戶機(jī)希望具有的緩沖器信用點(diǎn)的初始數(shù)量。 信用點(diǎn)的使用如下解釋。服務(wù)器可以滿足也可以不滿足客戶機(jī)的請(qǐng)求。若客戶機(jī)不 支持RDMA讀操作，Rd隨RdadSupport 653設(shè)成0，若客戶機(jī)支持RDMA讀，則設(shè)成
LWI0—AUTH_PARAMS結(jié)構(gòu)的部分是一個(gè)或多個(gè)選項(xiàng)的組。使用選項(xiàng)使認(rèn)證更靈
16
活。除了在列表中的最后選項(xiàng)LWI(UUJTH—0PTI0I^END外，每個(gè)選擇具有選項(xiàng)碼、 長度和數(shù)據(jù)，該最后選項(xiàng)只有選項(xiàng)碼，作為終止選項(xiàng)列表的空選項(xiàng)。在認(rèn)證消息中， 客戶機(jī)發(fā)送給服務(wù)器下列選項(xiàng)密鑰(LWIO—AUTH—OPTION—KEY)和簽名 (LWIO—AUTH—OPTION—SIGNATURE) 。 Key 655設(shè)成服務(wù)器以前在協(xié)商響應(yīng)中返回的 密鑰。Signature 657是除簽名以外的LWIO—AUTH—PARAMS 621的MD5簽署。
回到圖5，在步驟605，若在認(rèn)證消息中發(fā)送的Key匹配通過管道在協(xié)商響應(yīng) 中返回的密鑰，則服務(wù)器作為認(rèn)證響應(yīng)向客戶機(jī)RDMA發(fā)送LWIO—AUTH—PARAMS結(jié)構(gòu)， 它包括由客戶機(jī)在認(rèn)證消息中向DataVa地址及關(guān)聯(lián)的DataMh存儲(chǔ)器句柄提供的8 字節(jié)Sessionld。在步驟607，服務(wù)器發(fā)送LWIO_MSG_STATUS—RESPONSE以完成認(rèn)證。
圖6B提供在本發(fā)明的實(shí)施例中由服務(wù)器返回的LWIO—AUTH—PARAMS結(jié)構(gòu)659 的圖示，Magic 611設(shè)成'LWIO， 。 Revld 663設(shè)成LWID—REV—ID。 Endian 655設(shè)成 sizeof (UL0NG_PTR) 。 PageSize 667設(shè)成CPU頁大小。BaseSequence 669試圖設(shè)成 (客戶機(jī)的BaseSequewcetl) 。 MaxRdmaWindowSize 671試圖設(shè)成客戶機(jī)在RDMA傳 輸中能接受的最大字節(jié)數(shù)；在描述的實(shí)施例中設(shè)成512K。 MaxSendBufferSize673 試圖設(shè)成服務(wù)器在單個(gè)響應(yīng)中發(fā)送給客戶機(jī)的字節(jié)數(shù)；在描述的實(shí)施例中設(shè)成16 字節(jié)。MaxRecvBufferSize 675試圖設(shè)成為從客戶機(jī)接收數(shù)據(jù)服務(wù)器預(yù)發(fā)送的字節(jié) 數(shù)；在描述的實(shí)施例中設(shè)成8K。HeaderSize 667設(shè)成在共同首部的字節(jié)數(shù)。Credits 679被設(shè)成服務(wù)器對(duì)客戶機(jī)可用的初始信用點(diǎn)數(shù)。若服務(wù)器不支持RDMA讀，則 RdmaReadSupported681被設(shè)成0，若服務(wù)器支持RDMA讀，則設(shè)成l。服務(wù)器發(fā)送 下 列 選 項(xiàng) Key(LWIO—AUTH—OPTION—Key) 683 、 Sessionld (LWIO一AUTH一OPTION一SESSION—ID) 685 禾H Signature
(LWIO—AUTH—OPTION—SIGNATURE)687。 Key 683被設(shè)成客戶機(jī)以前在協(xié)商請(qǐng)求中發(fā) 送的Key。如下解釋，客戶機(jī)在向服務(wù)器注冊(cè)客戶機(jī)文件時(shí)使用該Sessionld 685 的值。Signature 687是LWIO—AUTH_PARAMS中除Signature外的MDS簽署。
在本發(fā)明MSG—STATUS—RESPONSE的實(shí)施例中，LWIO_MSG_STATUS—RESPONSE結(jié) 構(gòu)具有下述格式typedef struct —LWIO_IO—STATUS—BLOCK {
UINT32— _ 一 f^iformation'.
UINT32 Status,. } LWIO—IO一STATUS一BLOCK, *LPLWIO—IO—STATUS—BLOCK;
typedef struct —!LWIO_MSG_STATUS_RESPONSE {
UINT64— — — c"ie,.
LWIO—IO—STATUS_BLOCK Ios,. } lwio—MS^—s5aTUS—RESPONSE, *LPLWIO—MSG—status—response,
圖6C提供在本發(fā)明的實(shí)施例中為完成認(rèn)證由服務(wù)器返回的 LWIO—MSG_STATUS_RESP0NSE 689的圖示。Cookie 691被設(shè)成由客戶機(jī)在認(rèn)證消息 的首部中設(shè)置的Cookie值。Information (信息)693被設(shè)成LWI0_AUTH—PARAMS 的字節(jié)數(shù)加8個(gè)字節(jié)。Status 695設(shè)成0X0(表示成功)或0XC0000022 (表示"訪 問被拒絕")。
文件注冊(cè)
回到圖5，在步驟609，當(dāng)新的連接被客戶機(jī)及服務(wù)器互相認(rèn)證時(shí)，客戶機(jī)開 始注冊(cè)文件以供服務(wù)器使用。
圖7A提供在本發(fā)明的實(shí)施例中由客戶機(jī)向服務(wù)器發(fā)送的注冊(cè)文件消息的圖 示。注冊(cè)消息701包括共同首部703及隨后的LWIO—FID—PARAMS結(jié)構(gòu)705。 Length (長度)設(shè)成發(fā)送到服務(wù)器的字節(jié)數(shù)(首部703的長度加上LWIO—FID一PARAMS 705 的長度)。Opcode (操作碼)709設(shè)成LWI0—OPCODE—REGISTER (OX 7)。 Flags (標(biāo) 志)711設(shè)成LWI0—HDR—FLAG_INTERRUPT。在此客戶機(jī)消息及隨后的客戶機(jī)消息中， Credits (信用點(diǎn))713設(shè)成在客戶機(jī)上掛起的1/0請(qǐng)求的數(shù)量。如下進(jìn)一步解釋， Credits字段用作對(duì)服務(wù)器向連接分配更多信用點(diǎn)的暗示，從而允許額外的未完成 的1/0請(qǐng)求。在任何時(shí)刻未完成的客戶機(jī)請(qǐng)求的數(shù)量不能超過"Credits"值。如 前所述，Cookie 715設(shè)成客戶機(jī)指定的值。
在本發(fā)明的實(shí)施例中，LWI0一FID—PARRMS結(jié)構(gòu)具有下述格式
typedef struct {
SRV—RESUME—KEY ResumeKey
INT64 Sessionld,'
UINT32 FlagsAndAttributes'.
} LWIO—FID—PARAMS, *LP:LWIO—FID—PARAMS ,.
在注冊(cè)文件消息701的LWIO—FID—PARRMS 705中，Res咖eKey 717設(shè)成通過初 始文件訪問通道返回的服務(wù)器請(qǐng)求繼續(xù)鍵。Sessionld 719設(shè)成在連接認(rèn)證階段中
由服務(wù)器返回的Sessonld。 FlagsAndAttributes (標(biāo)志和屬性)721設(shè)成最初用于 打開文件的Win32創(chuàng)建標(biāo)志。
回到圖5，在步驟611，服務(wù)器用LWI0_MSG_STATUS_RESP0NSE作出響出以完 成文件注冊(cè)。圖7B提供在本發(fā)明中由服務(wù)器發(fā)送的LWIO—MSG一STATUS—RESPONSE 723的圖示。Information727設(shè)成Fid(文件ID)，在發(fā)送I/0請(qǐng)求時(shí)使用。Status (狀態(tài))729設(shè)成0X0 (成功)或在失敗時(shí)設(shè)成另外的NTSTATUS碼。Cookie 725 設(shè)成客戶機(jī)在注冊(cè)文件消息的首部中的Cookie值。
1/0處理
在此時(shí)，建立了客戶機(jī)連接，且文件已被注冊(cè)，并開始LWIO協(xié)議的1/0處理 階段。LWIO協(xié)議的實(shí)施例的一個(gè)關(guān)鍵特征是對(duì)讀和寫的非對(duì)稱1/0模型。讀操作 使用RDMA實(shí)現(xiàn)，而寫使用發(fā)送操作實(shí)現(xiàn)。不使用RDMA實(shí)現(xiàn)寫是為了提供更好的安 全模型。若服務(wù)器對(duì)RDMA展現(xiàn)NIC上的地址空間，它會(huì)引入能由惡意客戶機(jī)利用 的數(shù)據(jù)破壞的弱點(diǎn)。在此情況，惡意的客戶機(jī)在循環(huán)中發(fā)出給定服務(wù)器虛擬地址上 的RDMA寫操作。由于服務(wù)器地址空間是有限的，且在某一點(diǎn)服務(wù)器的虛擬地址必 須被重新使用，因此惡意客戶機(jī)最終捕捉服務(wù)器，對(duì)不同的連接使用同一虛擬地址， 導(dǎo)致數(shù)據(jù)被寫入到可能與不同的客戶機(jī)關(guān)聯(lián)的服務(wù)器緩存器。LWIO協(xié)議中的非對(duì) 稱I/O模型避免了這種可能性。此特征是LWIO協(xié)議和如DAFS等其它基于RDMA的 文件傳輸協(xié)議之間的主要差別。
回到圖5，在步驟613，客戶機(jī)開始發(fā)送I/0處理請(qǐng)求。服務(wù)器-客戶機(jī)的1/0 請(qǐng)求的完成是非輪詢模式或輪詢模式。在非輪詢模式中，1/0完成是基于中斷的， 使用普通的發(fā)送/接收消息。在輪詢模式中，I/O的完成是使用RDMA，且不是基于 中斷的。
從LWIO服務(wù)器的一般觀點(diǎn)來看，圖8的流程圖一般示出在本發(fā)明的實(shí)施例中 以輪詢模式或非輪詢模式完成I/O請(qǐng)求所采取的步驟?？蛻魴C(jī)I/O請(qǐng)求指定，服務(wù) 器是否應(yīng)當(dāng)發(fā)回后發(fā)送(post—send)(中斷CPU)或RDMA消息。在步驟801，服務(wù) 器確定是否在客戶機(jī)1/0請(qǐng)求消息的共同首部中的LWIO—HDR—FLAG—INTERRUPT標(biāo)志 是否被置位。若該標(biāo)志被置位，則在步驟803，服務(wù)器使用普通發(fā)送借助 LWI0_MSG—STATUS_RESPNSE完成客戶機(jī)請(qǐng)求。若LWIO—HDR—FLAG—INTERRUPT標(biāo)志未 被置位(輪詢模式)，則如步驟805所示，服務(wù)器通過用RDMA發(fā)送 LWIO—ID—STATUS—BLOCK到客戶機(jī)而完成客戶機(jī)請(qǐng)求。 在輪詢模式中喚醒客戶機(jī)
在輪詢模式中，客戶機(jī)希望在等待從服務(wù)器完成I/O的同時(shí)休眠。在此情況
借助RDMA將Completion (完成)發(fā)送到客戶機(jī)，所以需要一種機(jī)制來喚醒客戶機(jī)， 通知它完成已發(fā)生。若客戶機(jī)希望被喚醒，它發(fā)送中斷請(qǐng)求 (LWI0_0PC0DE—INTERRUPT)消息到服務(wù)器，由服務(wù)器在圖8的步驟807接收。接 收中斷請(qǐng)求的服務(wù)器在服務(wù)器完成I/0請(qǐng)求之前不發(fā)送響應(yīng)(步驟809)。在步驟 811借助普通發(fā)送，將"完成"發(fā)送到客戶機(jī)，中斷客戶機(jī)。對(duì)給定客戶機(jī)連接只 有一個(gè)中斷消息能是未完成的。
圖9A提供在本發(fā)明的實(shí)施例中由客戶機(jī)發(fā)給服務(wù)器的中斷請(qǐng)求消息的圖示。 消息包括共同的首部815。 Opcode (操作碼)817被置成LWI0_0PC0DE—REGISTER(0 X9)。標(biāo)志819被置成(LWI0—HDR—FLAG_INTERRUPT1 LWI0_HDR—FLAG—CONTROL) (0 XC0)。Credits(信用點(diǎn))821被置成在客戶機(jī)上掛起的1/0請(qǐng)求的數(shù)量，而Cookie 823被設(shè)置成客戶機(jī)指定的值。
在另一 1/0請(qǐng)求己被處理之后服務(wù)器響應(yīng)中斷請(qǐng)求消息。圖9B提供了在本發(fā) 明的實(shí)施例中由服務(wù)器發(fā)送的LWI0_MSG_STATUS_RESP0NSE消息825的圖示。 Information (信息)827設(shè)成0。 Status (狀態(tài))829設(shè)成0X0 (成功)，或在失 敗時(shí)設(shè)成另一NTSTATUS碼。Cookie 831設(shè)成由客戶機(jī)發(fā)送的中斷請(qǐng)求的首部中的 Cookie值。
信用點(diǎn)(Credits)
已經(jīng)提到，所有客戶機(jī)-服務(wù)器的i/o請(qǐng)求包括在首部的信用點(diǎn)字段。信用點(diǎn) 字段是對(duì)服務(wù)器關(guān)于客戶機(jī)發(fā)送給服務(wù)器的未完成的i/o信用點(diǎn)數(shù)的暗示。管理信
用點(diǎn)是服務(wù)器的責(zé)任。信用點(diǎn)提供對(duì)轉(zhuǎn)儲(chǔ)清除緩存器問題的新穎解決方法。若客戶 機(jī)當(dāng)前具有N個(gè)信用點(diǎn)，為了服務(wù)器向客戶機(jī)發(fā)送信用點(diǎn)消息，需要發(fā)送N+1個(gè)接 收緩存器。在任何一個(gè)時(shí)刻服務(wù)器沿客戶機(jī)連接只有一個(gè)未完成的信用點(diǎn)請(qǐng)求。信 用點(diǎn)消息總是以中斷模式發(fā)送。
信用點(diǎn)事務(wù)包括在客戶機(jī)和服務(wù)器之間由服務(wù)器啟動(dòng)的三路握手。圖10—般 示出包括在本發(fā)明的實(shí)施例中信用點(diǎn)事務(wù)的步驟。在步驟1001，服務(wù)器沿客戶機(jī) 連接發(fā)送增量信用點(diǎn)請(qǐng)求消息。
圖11A提供在本發(fā)明實(shí)施例中服務(wù)器增量信用點(diǎn)消息的圖示。此消息采取
LWIO—MSG_STATUS_RESPONSE 1011的形式。信用點(diǎn)對(duì)應(yīng)于緩存器。信息1013設(shè)成 客戶機(jī)應(yīng)放棄的信用點(diǎn)的數(shù)(負(fù)數(shù))或服務(wù)器新分配給客戶機(jī)使用的信用點(diǎn)(額外 的緩存器)的數(shù)量(正數(shù))。Status 1015設(shè)成LWIO—NOTIFY—CREDIT (OX 1) 。 Cookie 1017設(shè)成O。
回到圖10，客戶機(jī)從服務(wù)器接收信用點(diǎn)消息。需要客戶機(jī)在同一連接上用 LWI0_0PC0DE_CREDIT消息對(duì)服務(wù)器作出響應(yīng)。此消息表示釋放單個(gè)信用點(diǎn)或通知 服務(wù)器客戶機(jī)已使用的新分配的信用點(diǎn)數(shù)。若在服務(wù)器信用點(diǎn)消息中的信息字段包 含負(fù)數(shù)-N(步驟1003)，則如步驟1005表明，客戶機(jī)發(fā)送N個(gè)LWID一OPCODE一CREDIT 消息(對(duì)每個(gè)需要放棄的信用點(diǎn)一個(gè))。若信息字段是正，則如步驟1007表明， 客戶機(jī)只發(fā)送一個(gè)LWIO—OPCODE—CREDIT消息。
圖11B提供在本發(fā)明的實(shí)施例中由客戶機(jī)發(fā)送的LWIOJ)PCODE一CREDIT消息的 圖示。LWIO—0PC0DE_CREDIT消息1019包括共同的首部1021。 OPCODE 1023設(shè)成 LWIO—OPCODE—CREDIT(0X8) 。 Flags(標(biāo)志)1025設(shè)成LWIO_HDR_FLAG—INTERRUPT(0 X80) 。Credits(信用點(diǎn))1027設(shè)成在客戶機(jī)上掛起的I/O請(qǐng)求的數(shù)量。Cookie 1031 設(shè)成客戶機(jī)指定的值。若客戶機(jī)接收到正的增量信用點(diǎn)消息，則Offset (偏置)1029 的較高32位設(shè)成由服務(wù)器分配而客戶機(jī)未使用的信用點(diǎn)的數(shù)量。 一旦客戶機(jī)在此 字段返回大于零的值，在發(fā)送至少一個(gè)負(fù)的更新值之前，服務(wù)器通常不發(fā)送另一正 的更新消息。通?？蛻魴C(jī)返回零。
如上提到，若客戶機(jī)接收負(fù)(-N)增量信用點(diǎn)消息，則需要客戶機(jī)發(fā)送N個(gè) 信用點(diǎn)消息給服務(wù)器，對(duì)每個(gè)放棄的信用點(diǎn)一個(gè)。在此情況Offset1029的較高32 位相應(yīng)地設(shè)成-N,-(N-1)，…，-1。當(dāng)服務(wù)器接收其Off set 1029的較高32位被設(shè) 成-1的客戶機(jī)信用點(diǎn)消息時(shí)，服務(wù)器認(rèn)為客戶機(jī)已完成處理服務(wù)器信用點(diǎn)消息， 并適于接收新的信用點(diǎn)消息。
回到圖10，如步驟1009所示，服務(wù)器通過發(fā)送LWIO—MSG—STATUS—RESPONSE 消息到客戶機(jī)完成三路握手。圖11C提供在本發(fā)明的實(shí)施例中由服務(wù)器發(fā)送的 LWIO—MSG—STATUS—RESPONSE 1033的圖示。Information (信息)1037設(shè)成0。若 在由客戶機(jī)發(fā)送的LWI0_0PC0DE—CREDIT消息的首部中Offset (偏置)的較高32 位大于或等于0，則Status 1039設(shè)成0X0，表示成功。若Off set的較高32位設(shè) 成負(fù)數(shù)，則為了使客戶機(jī)能收回信用點(diǎn)，服務(wù)器將Status 1039設(shè)成 LWIO_CREDIT_NOTIFY。 Cookie 1035設(shè)成由客戶機(jī)在LWIO—OPCODE—CREDIT消息的 共同首部中設(shè)置的Cookie值。
關(guān)閉
關(guān)閉消息用于停止對(duì)在注冊(cè)階段交換的特定Fid的I/O處理。 一旦服務(wù)器作 出響應(yīng)，在Fid被回收之前任何新的請(qǐng)求將失敗。圖12A提供在本發(fā)明的實(shí)施例中 由客戶機(jī)發(fā)送的關(guān)閉消息的圖示。關(guān)閉消息1041包括共同的首部1043。0pcode(操 作碼)1045設(shè)成LWIO—OPCODE—CLOSE(0 X 4) 。 Flags (標(biāo)志)1047設(shè)成 LWI0_HDR—FLAG—INTERRUPT(0X80)。 Credits (信用點(diǎn))1049被設(shè)成在客戶機(jī)上掛 起的I/O請(qǐng)求的數(shù)量。Cookie 1053設(shè)成客戶機(jī)指定的值。Fid 1051設(shè)成擬關(guān)閉的 文件的文件id。
服務(wù)器用LWI0_MSG—STAUS_RESPONSE作出響應(yīng)。圖12B提供在本發(fā)明實(shí)施例 中由服務(wù)器返回的關(guān)閉完成LW10—MSG—STAUS—RESPONSE 1055的圖示。Information (信息)1059設(shè)成O。 Status(狀態(tài))1061設(shè)成0，表示成功。Cookie 1057設(shè)成在 客戶機(jī)關(guān)閉請(qǐng)求中設(shè)置的Cookie值。
取消
使用取消消息停止對(duì)在注冊(cè)階段交換的特定Fid的1/0處理。在發(fā)出取消時(shí)， 服務(wù)器程序完成請(qǐng)求。然而不能取消的1/0請(qǐng)求仍可在服務(wù)器上進(jìn)行。圖13A提供 在本發(fā)明的實(shí)施例中由客戶機(jī)發(fā)出的取消消息的圖示。取消消息1063包括共同的 首部1065。 Opcode 1067設(shè)成LWIO—OPCODE—CANCEL (0X5) 。 Flags (標(biāo)志)1069設(shè) 成LWI0—HDR—FLAG-INTERRUPT(0X80) 。 Credits (信用點(diǎn))1071設(shè)成在客戶機(jī)上掛 起的I/0請(qǐng)求的數(shù)量。Cookie 1075設(shè)成客戶機(jī)指定的值。Fid 1073設(shè)成發(fā)出取消 的文件的文件id。
服務(wù)器用LWI0_MSG—STATUS—RESPONSE消息完成取消。圖13B提供在本發(fā)明的 實(shí)施例中由服務(wù)器返回的取消完成LWIO_MSG_STATUS—RESPONSE1077的圖示。 Information (信息)1081設(shè)成O。 Status (狀態(tài))1083設(shè)成零，表示成功。Cookie 1079設(shè)成在客戶機(jī)取消請(qǐng)求中設(shè)置的Cookie值。
使用讀消息從在注冊(cè)階段被交換的特定Fid中獲取數(shù)據(jù)。對(duì)小于一千字節(jié)的 讀請(qǐng)求，若用戶的緩存器未向NIC注冊(cè)，則數(shù)據(jù)被接收到內(nèi)部的預(yù)注冊(cè)的緩存器中， 且一旦從服務(wù)器接收數(shù)據(jù)，將復(fù)制完成到用戶緩存器中。這樣做是因?yàn)閺?fù)制少量數(shù) 據(jù)比注冊(cè)小的用戶緩存器更有效。對(duì)大的讀，注冊(cè)用戶緩存器，并通過RDMA直接 接收數(shù)據(jù)。按照單次讀請(qǐng)求的讀數(shù)據(jù)的量受服務(wù)器的MaxRdraaWindowSize限制。圖14A和14C提供在本發(fā)明的實(shí)施例中由客戶機(jī)發(fā)送的讀消息的圖示，圖14A 給出非輪詢情況而圖14C給出輪詢情況。讀消息1401包括共同的首部1403。長度 1405設(shè)成擬從相關(guān)文件讀的字節(jié)數(shù)。Opcode (操作碼)1407設(shè)成 LWIO—OPCODE—READ(0X0)。 Offset (偏置)1417設(shè)成文件讀開始處的字節(jié)位置。 Marker(標(biāo)記)1413設(shè)成0XFF。 Flags (標(biāo)志)1409， 1427在輪詢情況1427設(shè)成0 X0，或在非輪詢情況1409設(shè)成LWI0JffilLFLAGjNTERRUPT(0X80)。 Credits (信 用點(diǎn))1411設(shè)成在客戶機(jī)中掛起的I/O請(qǐng)求的數(shù)量。Fid 1415設(shè)成發(fā)出I/O的文 件的文件id。 DataVa 1419設(shè)成要對(duì)讀數(shù)據(jù)進(jìn)行RDMA的位置，而DataMh 1421設(shè) 成關(guān)聯(lián)的存儲(chǔ)器句柄。
在非輪詢情況，IramediateCookie 1423和Cookie 1425設(shè)成用戶程序指定的 值。在此LWIO—MSG—STAUS—RESPONSE的情況下服務(wù)器借助常規(guī)發(fā)送完成讀請(qǐng)求，或 若讀成功，在RDMA的情況下用立即數(shù)據(jù)完成。因而RDMA寫的立即數(shù)據(jù)設(shè)成讀請(qǐng)求 的IramediateCookie值。在輪詢情況下，IosVa 1431設(shè)成對(duì)服務(wù)器響應(yīng)狀態(tài) (LWIO—I0_STATUS_BL0CK)進(jìn)行RDMA的位置，而IosMh 1429設(shè)成關(guān)聯(lián)的存儲(chǔ)器句 柄°
在非輪詢情況下，服務(wù)器首先對(duì)讀數(shù)據(jù)進(jìn)行RDMA。然后，服務(wù)器用 LWIO—MSG—STATUS—RESPONSE作出響應(yīng)，或服務(wù)器能用RDMA讀數(shù)據(jù)發(fā)送立即數(shù)據(jù)， 在此情況下立即數(shù)據(jù)設(shè)成讀請(qǐng)求的ImmediateCookie值。圖14B提供在本發(fā)明的實(shí) 施例中由服務(wù)器在非輪詢情況下返回的LWI0J1SG—STATUS—RESPONSE 1433的圖示。
Information (信息)1437設(shè)成讀的字節(jié)數(shù)，Status (狀態(tài))1439設(shè)成0，表 示成功，或設(shè)成另外的NTSTATUS，表示失敗。Cookie 1435設(shè)成由客戶機(jī)在讀消息 的首部中設(shè)置的Cookie值。
在輪詢情況下，服務(wù)器首先對(duì)讀數(shù)據(jù)進(jìn)行RDMA。然后服務(wù)器用RDMA發(fā)送 LWI0_I0—STATUS—BLOCK到客戶機(jī)。圖14D提供在本發(fā)明的實(shí)施例中由服務(wù)器返回 的LWIO—10—STATUS—BLOCK 1441的圖示。Information (信息)1443設(shè)成讀的字節(jié) 數(shù)。Status (狀態(tài))1445設(shè)成0，表示成功，或設(shè)成NTSTATUS，表示失敗。
寫
使用寫消息將數(shù)據(jù)放入在文件注冊(cè)期間被交換的特定Fid。使用普通的發(fā)送操 作發(fā)送所有寫數(shù)據(jù)。寫的數(shù)據(jù)量受服務(wù)器MaxRecvBufferSize的限制。若客戶機(jī)發(fā) 送比此更多數(shù)據(jù)，連接終止。
圖15A和15C提供在本發(fā)明的實(shí)施例中由客戶機(jī)發(fā)送的寫消息的圖示，圖15A 給出非輪詢情況而圖15C給出輪詢情況。寫消息1501包括共同的首部1503。長度 1505設(shè)成擬寫數(shù)據(jù)的字節(jié)數(shù)。Opcode 1507設(shè)成LWIO—OPCODE—WRITE(0X 1) 。Off set (偏置)1517設(shè)成幵始寫文件數(shù)據(jù)處的字節(jié)位置。Flags (標(biāo)志)1509、 1529在輪 詢情況1529被設(shè)成0X0，或在非輪詢情況1509設(shè)成LWIO—HDR_FLAG-INTERRUPT (0 X8)。 Marker(標(biāo)記)1513設(shè)成0XFF。 Credit 1511設(shè)成在客戶機(jī)處掛起的I/O請(qǐng) 求的數(shù)量。Fid 1515設(shè)成在其上發(fā)出I/O的File(文件)Id。擬寫的數(shù)據(jù)1527緊接 在寫消息的共同首部1503之后。
在非輪詢情況下，Cookie 1525設(shè)成客戶機(jī)指定的值，在輪詢情況下，IosVa 1533設(shè)成對(duì)服務(wù)器響應(yīng)狀態(tài)(LWIO—IO—STTAUS—BLOCK)進(jìn)行RDMA的位置，而 IosMhl531設(shè)成相關(guān)聯(lián)的存儲(chǔ)器句柄。
在非輪詢情況下，服務(wù)器用LWIO—MSG—STAUS-RESPONSE響應(yīng)寫消息。圖15B 提供在本發(fā)明的實(shí)施例中由服務(wù)器返回的LWIO—MSG—STATUS—RESPONSE 1535的圖 示。信息1539設(shè)成被寫的字節(jié)數(shù)。狀態(tài)1541設(shè)成0，表明成功，或設(shè)成另一 NTSTATUS，表明失敗。Cookie 1537設(shè)成在寫消息的首部由客戶機(jī)設(shè)置的Cookie 值。在輪詢情況下服務(wù)器對(duì)LW10—10—STATUS—BLOCK進(jìn)行RDMA。圖15D提供在本發(fā) 明的實(shí)施例中由服務(wù)器返回的LW10—10—STATUS—BLOCK 1543的圖示。Information (信息)1545設(shè)成被寫的字節(jié)數(shù)。Status (狀態(tài))1547設(shè)成0表示成功，或設(shè)成 另一 NTSTATUS表示失敗。
向量化讀
向量化讀用于從在注冊(cè)階段交換的特定Fid獲取數(shù)據(jù)，并在頁的基礎(chǔ)上將數(shù) 據(jù)散布到請(qǐng)求者的多個(gè)段。所有讀數(shù)據(jù)借助RDMA寫發(fā)送到請(qǐng)求者，對(duì)每個(gè)讀的段 從服務(wù)器進(jìn)行一次RDMA寫。從盤讀出的數(shù)據(jù)是連續(xù)的。寫的數(shù)據(jù)的量受到在單次 請(qǐng)求中描述的目標(biāo)頁的最大數(shù)量的限制。此限制是由sizeof(LWI0—RDMA—REGION) 劃分的服務(wù)器MaxRecvBufferSize。下面給出LWIO—REMA—REGION的結(jié)構(gòu)。
圖16A和16C提供在本發(fā)明的實(shí)施例中由客戶機(jī)發(fā)送的向量化讀消息的圖示， 圖16A給出非輪詢情況而圖16C給出輪詢情況。讀消息1401包括共同首部i603， 接著是一個(gè)或多個(gè)LWI(LREMA-REGION段1605、 1607。在首部1603， Length (長度) 1609設(shè)成擬從文件讀取的數(shù)據(jù)的字節(jié)數(shù)。Opcode 1611設(shè)成 LWIO—OPCODE—VEC—READ (OX 2)。 Offset (偏置)1621設(shè)成在開始讀文件數(shù)據(jù)處的
字節(jié)位置。Flags (標(biāo)志)1613， 1631在輪詢情況1631設(shè)成0X0，或在非輪詢情 況1613設(shè)成LWIO—HER_FLAG_INTERRUPT(0X80) 。 Marker (標(biāo)記)1617設(shè)成0XFF。 Credits 1615設(shè)成在客戶機(jī)掛起的I/O請(qǐng)求的數(shù)量。Fid 1619設(shè)成在其上發(fā)出I/O 的文件Id。NumPages 1623設(shè)成跟在共同首部1603后的LWIO—RDMA—REGION的數(shù)量。 PageSize 1625設(shè)成本地頁的字節(jié)數(shù)。
在非輪詢情況下，ImmediateCookie 1627和Cookie 1629被設(shè)成客戶機(jī)指定 的值。在LWIO—MSG—STATUS—RESPONSE的情況下服務(wù)器借助常規(guī)發(fā)送能完成向量化 讀請(qǐng)求，或若讀成功，在RDMA情況下用直接數(shù)據(jù)完成。因而RDMA寫的立即數(shù)據(jù)設(shè) 成讀請(qǐng)求的I隱ediateCookie 1627值。在輪詢情況下，IosVa 1635設(shè)成對(duì)服務(wù)器 響應(yīng)狀態(tài)(LWIO—10—STATUS_BLOCK)進(jìn)行RDMA的位置，而IosMh 1633設(shè)成關(guān)聯(lián)的 存儲(chǔ)器句柄。
共同的首部1603后面緊接足夠數(shù)目的LWIO—RDMA_REGION段1605、 1607以覆 蓋請(qǐng)求的長度。所有立即段必須是一頁大小。最后段可小于一頁，但它必須是后端 (backend)盤扇區(qū)大小的倍數(shù)。在本發(fā)明的實(shí)施例中，LWIO—RDMA—REGION具有如 下格式
typedef volatile struct {
PVOID64 DataVa,.
UINT32 DstsMh'.
UINT32 Length,. } LWIO—RDMA—REGION/
第一 LWIO—RDMA—REGION對(duì)應(yīng)于讀的第一 PageSize字節(jié)，第二 LWIO—RDMA—REGION 對(duì)應(yīng)于讀的第二 PageSize字節(jié)，等等。DataVa 1637設(shè)成標(biāo)志放置讀數(shù)據(jù)的頁開 始處的位置。DataMh 1639設(shè)成DataVa 1637的存儲(chǔ)器句柄。Length (長度)1641 設(shè)成對(duì)除最后區(qū)域外所有區(qū)域的PageSize 1625，對(duì)最后區(qū)域長度可以小一些，但 必須是后端盤扇區(qū)大小的倍數(shù)。
在非輪詢情況下，服務(wù)器首先對(duì)讀數(shù)據(jù)進(jìn)行RDMA。然而服務(wù)器能用 LWIO_MSG_STATUS—RESPONSE作出響應(yīng)，或用RDMA讀數(shù)據(jù)發(fā)送立即數(shù)據(jù)，在此情況， 立即數(shù)被設(shè)成讀請(qǐng)求的ImmediateCookie值。圖16B提供在本發(fā)明的實(shí)施例中非輪 詢情況由服務(wù)器返回的LWI0_MSG—STATUS—RESPONSE 1643的圖示。Information(信 息)1647設(shè)成讀字節(jié)數(shù)。Status (狀態(tài))1649設(shè)成0，表示成功，或另一 NTSTATUS， 表示失敗。Cookie 1645設(shè)成在向量化讀消息的首部由客戶機(jī)設(shè)置的Cookie值。
在輪詢情況下，服務(wù)器首先對(duì)讀數(shù)據(jù)進(jìn)行RDMA，然后服務(wù)器對(duì)WIO—I0_STATUS—BL0K進(jìn)行RDMA。圖16D提供在本發(fā)明的實(shí)施例中由服務(wù)器返回的 LWI0_I0—STATUS—BLOCK 1651的圖示。Information (信息)1653設(shè)成讀字節(jié)數(shù)。 Status (狀態(tài))1655設(shè)成0，表示成功，或設(shè)成另一 NTSTATUS，表示失敗。
向量化寫
向量化寫消息用于完成對(duì)在文件注冊(cè)中交換的特定Fid的集成的寫。所有寫 數(shù)據(jù)使用普通發(fā)送操作發(fā)送。寫的數(shù)據(jù)量受服務(wù)器的MaxRecvBufferSize的限制。 若客戶機(jī)發(fā)送多于此的數(shù)據(jù)，連接終止。
圖17A、 17B和17C提供在本發(fā)明的實(shí)施例中由客戶機(jī)發(fā)送的向量化寫消息的 圖示，圖17A示出非輪詢不崩潰情況，圖17B示出非輪詢崩潰情況，圖17C示出輪 詢崩潰情況。
寫消息1701包括共同首部1703，緊接著是擬寫的數(shù)據(jù)1705。在共同首部1703， 長度1707設(shè)成被寫的數(shù)據(jù)的字節(jié)數(shù)。Opcode 1709設(shè)成LWI0_0PC0DE_WRITE(0X3)。 Offset (偏置)1719設(shè)成在開始寫文件數(shù)據(jù)處的字節(jié)位置。Marker (標(biāo)記)1715 設(shè)成0XFF。 Credit (信用點(diǎn))1713設(shè)成在客戶機(jī)上掛起I/O信用點(diǎn)。Fid 1717 設(shè)成發(fā)出1/0處的文件Id。
Flags (標(biāo)志)1711、 1721、 1727設(shè)成0X0，表示輪詢1727，或否則設(shè)成 LWIO_HDR_FLAG—INTERRUPT (0 X 80) 1711 。在后面情況下，標(biāo)志也能包括 LWIO—HDR—FLAGJNTERRUPT1721，以表明在寫的所有頁面包含同樣數(shù)據(jù)，所以只發(fā) 送單個(gè)頁數(shù)據(jù)。這時(shí)試圖使重復(fù)數(shù)據(jù)的傳輸最小化的優(yōu)化。若注冊(cè)的文件標(biāo)志包括 FILE_NO_INTERMEDIATE—BUFFERING(0X8)和在認(rèn)證階段交換的PageSize互相成偶 數(shù)倍，則只能使用LWIOJTOR—FLAG—COLLAPSE。在崩潰的I/O的情況下，NumPage 1723 設(shè)成I/0覆蓋的數(shù)據(jù)的頁數(shù)。由于Length (長度)參數(shù)，最后頁面可以是部分的。 PageSize 1725設(shè)成本地頁面字節(jié)數(shù)。在輪詢情況下，IosVa 1731設(shè)成擬用RDMA 傳輸?shù)姆?wù)器響應(yīng)狀態(tài)(LWIO—10—STATUS_BLOCK)的位置。IosMh 1729與存儲(chǔ)器 句柄相關(guān)聯(lián)。
在非輪詢情況下，對(duì)非崩潰和崩潰的I/O情況，服務(wù)器用 LWIO—MSG—STATUS—RESPONSE對(duì)寫消息作出響應(yīng)。
圖17D提供在本發(fā)明的實(shí)施例中由服務(wù)器返回的LWIO—MSG—STATUS—RESPONSE 1733的圖示。Information (信息)1737設(shè)成寫的字節(jié)數(shù)。Status (狀態(tài))1739 設(shè)成0，表示成功，或設(shè)成另一 NTSTATUS，表示失敗。Cookie 1735設(shè)成由客戶機(jī)
在寫消息首部設(shè)置的Cookie值。
在輪詢情況下，對(duì)于非崩潰和崩潰的1/0，服務(wù)器對(duì)LWIO—10—STATS—BLOCK 進(jìn)行RDMA。圖17E提供在本發(fā)明的實(shí)施例中由服務(wù)器返回的LWIO—I0_STATS—BLOCK 1741的圖示。Information (信息)1743設(shè)成寫的字節(jié)數(shù)。Status (狀態(tài))1745 設(shè)成0，表示成功，或設(shè)成另一NTSTATUS，表示失敗。
結(jié)論
雖然已圖示及描述了本發(fā)明的圖示實(shí)施例，然而可以理解，在不偏離本發(fā)明 的情況可作出各種改變。類似地，這里描述的任何處理步驟可與其它步驟互換以達(dá) 到同樣結(jié)果。此外，上述的圖示例子不是包括一切或試圖將本發(fā)明限于描述的精確 形式。相反，其目的是覆蓋落在本發(fā)明的精神及范圍內(nèi)的所有修改、更換、結(jié)構(gòu)和 等價(jià)技術(shù)方案。
權(quán)利要求
1.一種用于將輸入/輸出(I/O)任務(wù)從第一計(jì)算機(jī)下傳的第二計(jì)算機(jī)的系統(tǒng)，其特征在于，包括在所述第一計(jì)算機(jī)上運(yùn)行的客戶機(jī)；在所述第二計(jì)算機(jī)上運(yùn)行的服務(wù)器；以及鏈接所述第一計(jì)算機(jī)和第二計(jì)算機(jī)的至少一個(gè)RDMA通道，其中，所述第一計(jì)算機(jī)和第二計(jì)算機(jī)按包括網(wǎng)絡(luò)發(fā)現(xiàn)階段和I/O處理階段的協(xié)議進(jìn)行通信。
2. 如權(quán)利要求l所述的系統(tǒng)，其特征在于，在所述I/0處理階段，讀操作 是使用RDMA來實(shí)現(xiàn)的，而寫操作是使用發(fā)送操作來實(shí)現(xiàn)的。
3. 如權(quán)利要求l所述的系統(tǒng)，其特征在于，所述協(xié)議是結(jié)合第二網(wǎng)絡(luò)協(xié)議 來使用的。
4. 如權(quán)利要求3所述的系統(tǒng)，其特征在于，所述第二協(xié)議是SMB。
5. 如權(quán)利要求3所述的系統(tǒng)， 其特征在于，所述第二協(xié)議是CIFS。
6. —種計(jì)算機(jī)可執(zhí)行指令和計(jì)算機(jī)可讀數(shù)據(jù)的計(jì)算機(jī)可讀介質(zhì)，包括在將 輸入/輸出(I/O)任務(wù)從第一計(jì)算機(jī)下傳到第二計(jì)算機(jī)的系統(tǒng)中使用的計(jì)算機(jī) 程序產(chǎn)品，其特征在于，所述系統(tǒng)包括鏈接所述第一計(jì)算機(jī)和第二計(jì)算機(jī)的至少一個(gè)RDMA通道，其中，所述第 一計(jì)算機(jī)和第二計(jì)算機(jī)按包括網(wǎng)絡(luò)發(fā)現(xiàn)階段和I/O處理階段的協(xié)議進(jìn)行通信。
7. —種用于將輸入/輸出(I/O)任務(wù)從第一計(jì)算機(jī)下傳到第二計(jì)算機(jī)的方 法，其特征在于，包括由所述第一計(jì)算機(jī)上的客戶機(jī)和所述第二計(jì)算機(jī)上的程序程序發(fā)現(xiàn)一個(gè) 或多個(gè)共享的能進(jìn)行RDMA的提供者；以及由所述客戶機(jī)發(fā)送I/O處理請(qǐng)求，以供所述第二計(jì)算機(jī)上的服務(wù)器完成。
8. 如權(quán)利要求7所述的方法，其特征在于，發(fā)現(xiàn)一個(gè)或多個(gè)共享的能進(jìn)行 R匿A的提供者還包括由所述客戶機(jī)從所述服務(wù)器獲得服務(wù)器請(qǐng)求繼續(xù)鍵； 由所述客戶機(jī)打開通向所述服務(wù)器的管道； 由所述客戶機(jī)經(jīng)過所述管道發(fā)送協(xié)商請(qǐng)求；以及由所述服務(wù)器經(jīng)過所述通道發(fā)送包括共同提供者的最小列表的協(xié)商響應(yīng)。
9. 如權(quán)利要求7所述的方法，其特征在于，還包括 由所述客戶機(jī)創(chuàng)建經(jīng)過共享的能進(jìn)行RDMA的提供者到所述服務(wù)器的RDMA 連接；以及由所述客戶機(jī)及所述服務(wù)器認(rèn)證所述RDMA連接。
10. 如權(quán)利要求9所述的方法，其特征在于，還包括-由所述客戶機(jī)通過所述RDMA連接向所述服務(wù)器注冊(cè)一個(gè)或多個(gè)文件。
11. 如權(quán)利要求IO所述的方法，其特征在于，所述注冊(cè)一個(gè)或多個(gè)文件包括由所述客戶機(jī)向所述服務(wù)器發(fā)送注冊(cè)文件消息；以及 由所述服務(wù)器向所述客戶機(jī)發(fā)送注冊(cè)文件完成消息。
12. 如權(quán)利要求9所述的方法，其特征在于，所述認(rèn)證RDMA連接還包括 由所述客戶機(jī)向所述服務(wù)器發(fā)送包括密鑰的認(rèn)證請(qǐng)求消息； 若所述密鑰匹配以前由所述服務(wù)器向所述客戶機(jī)發(fā)送的密鑰，則由所述服務(wù)器向所述客戶機(jī)發(fā)送認(rèn)證響應(yīng)消息。
13. 如權(quán)利要求12所述的方法，其特征在于，所述之前的密鑰是包含在由所述服務(wù)器向所述客戶機(jī)發(fā)送的協(xié)商響應(yīng)消息中的密鑰。
14. 如權(quán)利要求12所述的方法，其特征在于，還包括由所述服務(wù)器向所述客戶機(jī)發(fā)送一狀態(tài)響應(yīng)消息，以完成所述認(rèn)證。
15. 如權(quán)利要求7所述的方法，其特征在于，所述發(fā)送I/O處理請(qǐng)求包括由所述客戶機(jī)發(fā)送下列之一(a)關(guān)閉請(qǐng)求，(b)取消請(qǐng)求，(C)讀請(qǐng)求，(d)寫請(qǐng)求，(e)向量化讀請(qǐng)求，和(f)向量化寫請(qǐng)求。
16. 如權(quán)利要求15所述的方法，其特征在于，還包括 由所述服務(wù)器通過使用RDMA寫操作發(fā)送數(shù)據(jù)來完成所述讀請(qǐng)求和所述向量化讀請(qǐng)求；以及由所述服務(wù)器通過使用常規(guī)發(fā)送操作發(fā)送數(shù)據(jù)來完成所述寫請(qǐng)求和所述 向量化寫請(qǐng)求。
17. 如權(quán)利要求15所述的方法，其特征在于，所述向量化寫請(qǐng)求包括所述 請(qǐng)求的首部的崩潰標(biāo)志。
18. 如權(quán)利要求7所述的方法，其特征在于，發(fā)送所述I/O請(qǐng)求還包括表 明所述服務(wù)器是否應(yīng)以輪詢模式完成。
19. 如權(quán)利要求18所述的方法，其特征在于，表明是否以輪詢模式完成包 括通過在所述I/O處理請(qǐng)求的首部中設(shè)置中斷標(biāo)志來表明不應(yīng)以輪詢模式完 成。
20. 如權(quán)利要求18所述的方法，其特征在于，還包括若所述客戶機(jī)表明不應(yīng)以輪詢模式完成，則由所述服務(wù)器借助RDMA傳輸 通過向所述第一計(jì)算機(jī)發(fā)送狀態(tài)塊來完成所述I/O處理請(qǐng)求。
21. 如權(quán)利要求18所述的方法，其特征在于，還包括若所述客戶機(jī)表明應(yīng)以輪詢模式完成，且所述客戶機(jī)己向所述服務(wù)器發(fā)送 中斷請(qǐng)求消息，則由所述服務(wù)器借助普通發(fā)送向所述客戶機(jī)發(fā)送中斷響應(yīng)消息。
22. 如權(quán)利要求7所述的方法，其特征在于，所述發(fā)送I/O處理請(qǐng)求還包 括在所述請(qǐng)求的首部指定信用點(diǎn)數(shù)。
23. —種存儲(chǔ)用于實(shí)現(xiàn)將輸入/輸出(I/O)任務(wù)從第一計(jì)算機(jī)下傳到第二 計(jì)算機(jī)的方法的計(jì)算可執(zhí)行指令的計(jì)算機(jī)可讀介質(zhì)，所述方法包括由所述第一計(jì)算機(jī)上的客戶機(jī)和所述第二計(jì)算機(jī)上的服務(wù)器發(fā)現(xiàn)一個(gè)或多個(gè)共享的能進(jìn)行RDMA的提供者；以及由所述客戶機(jī)發(fā)送1/0處理請(qǐng)求，以供所述第二計(jì)算機(jī)上的服務(wù)器完成。
24. —種用于管理輸入/輸出下傳協(xié)議中的緩存器的方法，其特征在于，所述方法包括由服務(wù)器向客戶機(jī)發(fā)送包括設(shè)成信用點(diǎn)數(shù)的信息字段的增量信用點(diǎn)消息，其中，若所述數(shù)字是負(fù)數(shù)-N，則所述服務(wù)器請(qǐng)求所述客戶機(jī)收回N個(gè)信用點(diǎn)； 若所述信用點(diǎn)數(shù)是負(fù)數(shù)-N，則由所述客戶機(jī)向所述服務(wù)器發(fā)送N個(gè)信用點(diǎn)消息，而否則由所述客戶機(jī)向所述服務(wù)發(fā)送一信用點(diǎn)消息；以及對(duì)每個(gè)由所述客戶機(jī)發(fā)送的信用點(diǎn)消息，由所述服務(wù)器向所述客戶機(jī)發(fā)送狀態(tài)響應(yīng)消息。
全文摘要
揭示了使用能進(jìn)行RDMA的網(wǎng)絡(luò)互連從第一計(jì)算機(jī)(圖1，101)向第二計(jì)算機(jī)(121)下傳I/O處理的方法和系統(tǒng)。該方法和系統(tǒng)包括第一計(jì)算機(jī)(101)上的客戶機(jī)(103)，它借助輕型輸入/輸出(LWIO)協(xié)議通過RDMA連接(117)與第二計(jì)算機(jī)(121)上的服務(wù)器(123)通信。該協(xié)議通常包括網(wǎng)絡(luò)發(fā)現(xiàn)階段及隨后的I/O處理階段。在發(fā)現(xiàn)階段，客戶機(jī)(103)和服務(wù)器(123)確定共享的能進(jìn)行RDMA的提供者的最小列表。在I/O處理階段，客戶機(jī)(103)發(fā)送I/O請(qǐng)求以便通過互相認(rèn)證的RDMA通道(117)下傳到第二機(jī)器(121)。I/O模型是非對(duì)稱的，讀操作使用RDMA實(shí)現(xiàn)而寫操作使用常規(guī)的發(fā)送實(shí)現(xiàn)。能以輪詢和中斷模式完成讀和寫的請(qǐng)求。通過信用點(diǎn)機(jī)制管理緩存器。
文檔編號(hào)G06FGK101375263SQ200480001333
公開日2009年2月25日 申請(qǐng)日期2004年7月26日 優(yōu)先權(quán)日2003年12月31日
發(fā)明者A·F·弗爾梅, A·H·莫哈米德 申請(qǐng)人:微軟公司