190_090-033AP-TW
發佈日期 :
2009-04-29
| 發明專利說明書 | |
| ※申請案號： | |
| ※申請日期： ※ＩＰＣ分類： | |
| 一、發明名稱： (中文/英文)
|
|
|
微軟視窗作業系統下具通透性之差異性服務封包標住方法(全文下載) / A Transparent Packet Pre-marking Method forDiffServ in Microsoft windows system
|
|
| 二、申請人： 共 人
|
|
| 指定 為應受送達人
|
|
| 三、發明人： | |
| ◎專利代理人： | |
| 四、聲明事項 | |
|
|
|
| □主張專利法第二十七條第一項國際優先權：
|
|
| □主張專利法第二十九條第一項國內優先權：
|
|
| □ 主張專利法第二十六條微生物：
|
|
| □ 熟習該項技術者易於獲得，不須寄存 | |
| 五、中文發明摘要： | |
| 一種微軟視窗作業系統下具通透性之差異性服務封包標註方法，主要係在目標行程(即應用程式)中插入攔截程式碼，而藉由該攔截程式碼得以變更IP標頭裡TOS欄位的值，以在微軟視窗作業系統下實現QoS Library Redirection(QLR，具透通性之差異性服務封包標註方法)，此種方法能夠將現有微軟視窗作業系統下之網際網路的應用程式，在不需要修改任何應用程式原始碼之狀況下，即能使應用程式達到具有封包標註的能力，使用者在執行應用程式之前，僅藉由選擇其所需的服務品質類型，此應用程式即能具有標註封包的能力。 | |
| 六、英文發明摘要： | |
| 七、指定代表圖： | |
| （一）本案指定代表圖為： | |
| （二）本代表圖之元件代表符號簡單說明：
|
|
| 八、本案若有化學式時，請揭示最能顯示發明特徵的化學式： | |
| 九、發明說明： | |
| 【技術領域】 本發明係關於一種微軟視窗作業系統下具通透性之差異性服務封包標註方法，主要係在目標行程中插入攔截程式碼，而藉由該攔截程式碼得以變更IP標頭裡TOS(Type-Of-Service)欄位的值，使用者在執行應用程式之前，僅藉由選擇其所需的服務品質類型，此應用程式即能具有標註封包的能力。 [先前技術] 近年來全球網際網路上線人數急速地成長，人們的使用網路的應用與需求各不同，而目前網際網路架構仍只提供盡其所能(best-effort)的服務，在此模式服務當中，所有使用者欲傳送或接收的封包，皆需共同競爭網路的資源，因此，此種服務模式並不適合於即時性多媒體的應用程式，例如：視訊會議、遠距醫療、網路電話等等，這些即時性多媒體應用程式對其封包於網路上傳輸的服務品質，是非常敏銳地。未來，網際網路將不只提供best-effort服務，同時也將提供不同的服務品質給不同的使用者，相信這樣的方式將可以使得網路資源的使用更合理化，而每個人亦可以依自己所需服務的重要性來選擇是否多付出一些代價，以得到更好的服務品質，這是使用者付費的精神。差異性服務(Differentiated Services)架構乃實現服務品質於IP網路上，它能在網際網路上提供多種服務等級的選擇並且可防止延展性與複雜性的問題。在差異性服務架構下通常封包由網路的邊界路由器(edge router)或來源端(source host)設定IP標頭內TOS(Type-Of-Service)欄位來完成封包的分類及標註，以達到服務等級的差別，同時，在網路核心路由器(core router)只需依照其TOS欄位之值處理其封包即可。在此機制下，目前封包標註的工作通常都於邊界路由器所完成，同時，必須由使用者告知系統管理者所需的服務品質之等級，系統管理者再於邊界路由器作靜態的設定，此後，邊界路由器一經系統管理者設定完成，使用者即不能即時性的做動態調整服務品質的等級，並且設定完成後，邊界路由器便將此使用者所送出的封包全都加以標註或將整個應用程式的封包都加以標註，對使用者而言是較缺乏彈性的。因此若能於來源端完成封包標註的工作，對使用者來說，要求所需要的服務品質較能具有彈性，可即時性動態地變更所需要的服務品質，選擇需要服務品質的應用程式加以標註，使得使用者能依照當時網路流量多寡、應用程式需不需要服務品質，來即時地決定是否將於封包標註。然而要於來源端完成封包標註可由下列兩種解決之辦法：其中一種方法，即為重新設計一個具封包標註之應用程式，第二種方式，則是藉由修改現有的資源(例如：函式庫、應用程式)來達到目的，然而，上述之第一種方式，必須花費龐大的成本，第二種方式不管是修改協定堆疊 (protocol stack)，即修改函式庫，或修改應用程式，對使用者來說，都存在於原始碼是不容易取得的，對於函式庫提供之公司而言，要修改其協定堆疊需花費龐大的成本，同時，使用者或程式設計師，並非個個都懂得封包標註的技術與觀念。 由此可見，欲於來源端完成封包標註之技術，在使用上仍缺乏彈性，非一完善之設計，而亟待加以改良。 本案發明人鑑於上述欲於來源端完成封包標註之技術所衍生的各項缺點，乃亟思加以改良創新，並成功研發完成本件微軟視窗作業系統下具通透性之差異性服務封包標註方法。 【發明目的】 本發明之目的即在於提供一種微軟視窗作業系統下具通透性之差異性服務封包標註方法，係在目標行程中插入一攔截程式碼，而藉由該攔截程式碼得以變更IP標頭裡TOS欄位的值，以在微軟視窗作業系統下實現QoS具透通性之差異性服務封包標註方法者。 本發明之另一目的係在於提供一種微軟視窗作業系統下具通透性之差異性服務封包標註方法，係僅藉由改變組態檔之內容，即可達適用於各微軟視窗作業系統之各網際網路應用程式。 本發明之他一目的係在於提供一種微軟視窗作業系統下具通透性之差異性服務封包標註方法，藉由本發明之步驟方法，即可達到由使用者選擇其所需的服務品質類型之功效，而不需經由重新設計一個具封包標註之應用程式或修改現有的資源，可節省花費龐大的成本及時間，而使用者或程式設計師也不必完全懂得封包標註的技術與觀念，即可使用此服務之技術。 【技術內容】 可達成上述發明目的之一種微軟視窗作業系統下具通透性之差異性服務封包標註方法，其步驟至少包括： 步驟一：建立一個組態檔，內容至少包括被攔截函式的名稱、被攔截函式所屬動態連結函式庫(Dynamic Link Library，DLL)名稱及被攔截函式內之參數等相關資料(組態檔中攔截函式之選定’依不同之目標行程函式內容而有所不同)。 步驟二：撰寫一程式載入器並執行之，因為攔截程式的設計目的為不修改被攔截程式的原始碼，且又必須將攔截程式碼安插於被攔截程式的行程範疇中，所以表示攔截程式必須是一個動態連結函式庫，在理論情況下，應設法要求目標行程去呼叫LoadLibrary載入攔截程式碼，但因為不能改變目標行程中被攔截函式，故須另外撰寫一個程式載入器，載入所欲執行之程式至記憶體中執行，並成為一常駐於記憶體之程式，即藉由該載入器之執行，會針對組態檔產生一攔截程式，該攔截程式為一動態連結函式庫，內含程式碼和資料，而該載入器另可針對目標行程呼叫一載入函式庫(LoadLibrary)，該載入函式庫被載入器呼叫之後，加上一中斷點指令，此時，載入器可將攔截程式碼位址寫入目標行程的第一個頁(page)中，並且改變目標行程的EIP(ExtendedInstruction Pointer)暫存器。 步驟三：設定好記憶體和暫存器之後，讓目標行程開始執行，目標行程會先執行起載入器，然後觸及該步驟二所述之中斷點指令，該中斷點指令一被觸發，該目標行程就暫時被凍結，而使得該攔截程式獲得優先控制權，藉由於該攔截程式內，記錄了該目標行程中欲被攔截函式所屬各項資料(如被攔截函式名稱)，於是攔截程式恢復目標行程原定之執行流程(包括記憶體和暫存器)，攔截程式碼因此而被悄悄地載入目標行程中。 步驟四：當目標行程執行過程中呼叫被攔截函式時，控制權先由攔截程式取得，而再由攔截程式將控制權交給原來目標行程想要呼叫的被攔截函式並執行之。 步驟五：被攔截函式執行完後，控制權交還給攔截程式，藉由攔截程式呼叫一屬性設定函式，並藉由該屬性設定函式來修改IP標頭裡TOS欄位，最後將控制權回傳給目標行程，如此QLR即完成，目標行程所產生的封包也悄悄地被標註。 [圖式簡單說明] 請參閱以下有關本發明一較佳實施例之詳細說明及其附圖，將可進一步瞭解本發明之技術內容及其目的功效；有關該實施例之附圖為： 圖一(A)為習知之目標行程執行流程示意圖；圖一(B)為習知之目標行程執行流程加入攔截程式示意圖；圖二為本發明之微軟視窗作業系統下具通透性之差異性服務封包標註方法之步驟流程示意圖；圖三為該微軟視窗作業系統下具通透性之差異性服務封包標註方法之測試平台中所使用CBQlink-sharing structure示意圖；圖四為該微軟視窗作業系統下具通透性之差異性服務封包標註方法之實驗架構圖；圖五為該微軟視窗作業系統下具通透性之差異性服務封包標註方法之測試設備之軟體示意圖；圖六為該微軟視窗作業系統下具通透性之差異性服務封包標註方法之在Henry主機上使用QLR與無使用QLR應用程式的throughput(單位時間所處理的量)比較圖；圖七為該微軟視窗作業系統下具通透性之差異性服務封包標註方法之利用TTT在Grace主機未使用QLR的輸出介面上所觀察示意圖；圖八為該微軟視窗作業系統下具通透性之差異性服務封包標註方法之利用TTT在Grace主機使用QLR的輸出介面上所觀察示意圖；圖九(A)、(B)為該微軟視窗作業系統下具通透性之差異性服務封包標註方法之主機Henry和主機Bob視窗在vic應用程式使用QLR前之視圖；以及圖十(A)、(B)為該徹軟視窗作業系統下具通透性之差異性服務封包標註方法之主機Henry和主機Bob視窗在vic應用程式使用QLR後之視圖。 【較佳實施例】 請參看圖一(A)，在習知一般狀況中，目標行程1(應用程式)在執行時，該目標行程1會去動態連結作業系統中的共享函式庫，載入目標行程所需之動態連結函式庫2A(在此假定為winsock. dll)，而在一個目標行程1中需要多次呼叫同一個動態連結函式庫2A時，它的每一個呼叫動作，都會把控制權轉移到一個指標3A(DWORD)，然後跳到指標3A(DWORD)所指之處，亦即目標行程1所連結之真正位址，而DWORD函式位址可以從輸入位址表4A(Import AddressTable-IAT)中獲得；輸入位址表4通常置於可執行檔的idata section中，目標行程1之可執行檔(在此假定為LegacyAPP.exe)所連結的每一個動態連結函式庫2A，都有一個對應的DWORD陣列5A，內含此動態連結函式庫2A之輸入函式51A(Import Function)之位址，故欲達到QLR的目的，只需要在目標行程1之可執行檔的輸入區段52A(Imports Section)中找到輸入位址表4A，改寫其內容，使其中的指標3A(DWORD)改指向攔截程式2之程式碼(假定攔截程式為Stub)即可，如圖一(B)所示。 請配合參看圖二，在此藉由詳述本發明施行如何攔截目標行程1來達到QLR目的五個步驟： 步驟一，建立一個組態檔3，該組態檔3內容至少包括被攔截函式2A1(假設為Socket())的名稱、被攔截函式所屬動態連結函式庫名稱2A及被攔截函式內之參數等相關資料。 步驟二，撰寫一程式載入器4並執行之，該載入器4為一常駐於記憶體之程式，即，藉由該載入器4之執行，會針對組態檔3產生一攔截程式2(假定為 stub()))，該攔截程式2之屬性為一動態連結函式庫，內含程式碼和資料，而該載入器4另可針對目標行程1呼叫一載入函式庫41(LoadLibrary)，該載入函式庫41被載入器4呼叫之後，加上一中斷點指令42，此時，載入器4可將攔截程式2之碼位址寫入目標行程1的第一個page中，並且改變目標行程1的EIP(Extended Instruction Pointer)暫存器。 步驟三：設定好記憶體和暫存器之後，讓目標行程1開始執行，目標行程1會先執行起載入器4，然後觸及該步驟二所述之中斷點指令42，該中斷點指令42一被觸發，該目標行程1就暫時被凍結，而使得該攔截程式2獲得優先控制權，藉由於該攔截程式2內，記錄了該目標行程中1欲被攔截函式所屬各項資料(如被攔截函式2A1名稱)，於是攔截程式2恢復目標行程1原定之執行流程(包括記憶體和暫存器)，攔截程式2之程式碼因此而被悄悄地載入目標行程1中。 步驟四：當目標行程1執行過程中呼叫被攔截函式2A1時，控制權先由攔截程式2取得，而再由攔截程式2將控制權交給原來目標行程1想要呼叫的被攔截函式2A1並執行之。 步驟五：被攔截函式2A1執行完後，控制權交還給攔截程式2，藉由攔截程式2呼叫一屬性設定函式2A2(在此假定為setsockopt())，藉由該屬性設定函式2A2來修改IP標頭裡TOS欄位，最後，再將控制權回傳給目標行程1，如此QLR即完成，目標行程1所產生的封包也悄悄地被標註。 為了在徹軟視窗作業系統平台驗證QLR方法，我們不只建構了一個DiffServ測試平台，同時實驗了兩種典型傳輸層協定(TCP/UDP)來佐證其結果。於TCP實驗中，我們使用了CuteFTP 及 Serv-U兩種應用程式；於UDP中則使用了MbOne軟體中的vic多媒體應用程式，vic為典型MbOne軟體上即時性視訊會議之多媒體應用程式。測試平台主要內容包括CBQ、DiffServ daemon及相關應用程式。 該CBQ(ClassBased Queueing)係藉由 Hierarchical link-Sharing structure觀念提供了在local host之界面上作封包排程機制，而不是在存取共享網路上作流量控制，其由Sally Floyed及Van Jacobson所提出，係藉由樹狀結構的方式，建立link-Sharingstructure。 請配合參看圖三、圖四及圖五，圖三係為我們的測試平台中所使用CBQ link-sharing structure。Diffserv daemon則提供於輸入界面中具有能力分類及監測流量並且將其結果送於輸出界面上。圖四了為我們實驗架構圖，其中有三台主機61(Bob)、62(Henry)及63(Liza)和一台路由器7(Grace)，該主機62及63為傳送流量主機。接收端主機61為兩個主機62及63流量之目的地；主機62使用具有QLR的應用程式，而主機63則是使用無QLR的應用程式產生網路壅塞(作業系統為FreeBSD，請配合參看圖四)，路由器7上的界面為10Mbps之點對點的Ethernet網路，而如圖六中所示，路由器7中包含了CBQ、DiffServ daemon及一些應用程式，例如：TTT、vic及Mgen，Mgen是一個在IP網路環境下提供產生uni-cast及multi-cast流量的流量產生器，它同時也能測量出網路效能並做成統計資料，TTT(TeleTraffic Tapper)是一個由FreeBSD提供的即時性測量網路流量程式，以圖型介面方式來表示出網路上各hOst及IP所產生的資料流量曲線，並且以自動方式監視網路上主要之流量，它的另一項不錯功能為遠端監視流量；CuteFTP及Serv-U為目前微軟視窗作業系統中較普遍性的FTP主從端(Client及Server)之應用程式。 TCP實驗實驗中我們在主機62上傳送了一個24Mbytes的檔案給主機61，同時在主機63產生不同等級的流量影響網路。圖六為在主機61上使用QLR與無使用QLR應用程式的throughput(單位時間所處理的量)比較圖。圖七及圖八為利用TTT在路由器7的輸出介面上所觀察的圖，由圖中可清楚得知使用QLR的應用程式並不會隨著網路的壅塞而減少其QoS(throughput)；而UDP實驗實驗中我們在主機62 上開啟一個vic session並傳送畫面，並於主機61端為Vic session的接收，在主機63上則產生大量流量使得網路壅塞，圖九(A)、(B)和圖十(A)、(B)表示主機62和61視窗在vic應用程式使用QLR之前/後圖形，當主機62端的vic應用程式沒有使用QLR之前，主機61端的畫面有很明顯的影像嚴重失真，使用QLR的主機62端vic應用程式將所產生的封包標註以達到所需的QoS。 現有的技術當中若要於來源端(source host)選擇其所需要的QoS，即時性服務中封包標註，必須重新設計或者修改其原始碼，甚至提出新的模式使得使用者具有選擇QoS的能力。QLR將可避免應用程式重新設計或修改的缺點，同時使用者也將不需要重新學習使用新的使用方法，使用目標行程1(應用程式)前，使用者只需選擇其所想要的服務等級即可。 【特點及功效】 本發明所提供之一種微軟視窗作業系統下具通透性之差異性服務封包標註方法，與前述其他技術相互比較時，更具有下列之優點： (1)本發明之步驟方法，僅藉由改變組態檔之內容，即可適用於各微軟視窗作業系統之各應用程式。 (2)藉由本發明之步驟方法，即可達到由使用者選擇其所需的服務品質類型之功效，不需經由重新設計一個具封包標註之應用程式或修改現有的資源原始碼，因此可節省花費龐大的成本及時間，而使用者或程式設計師也不必完全懂得封包標註的技術與觀念，即可使用。 (3)對於能由來源端完成封包標註的工作，對使用者來說，要求所需要的服務品質較能具有彈性，可即時性動態地變更所需要的服務品質，選擇需要服務品質的應用程式加以標註，使得使用者能依照當時網路流量多寡、應用程式需不需要服務品質，來即時地決定是否將於封包標註，對於使用者來說是較具有彈性的。 上列詳細說明係針對發明之一可行實施例之具體說明，惟該實施例並非用以限制本發明之專利範圍，凡未脫離本發明技藝精神所為之等效實施或變更，例如：變換應用程式或其內含之函式名稱等變化之等效性實施例，均應包含於本案之專利範圍中。 綜上所述，本案不但在構思上確屬創新，並能較習用技術增進上述多項功效，應已充分符合新穎性及進步性之法定發明專利要件，爰依法提出申請，懇請貴局核准本件發明專利申請案，以勵創作，至感德便。
|
|
| 十、申請專利範圍： | |
| 1.一種微軟視窗作業系統下具通透性之差異性服務封包標註方法，至少包括下列步驟：步驟一，建立一個組態檔，該組態檔內容至少包括：被攔截函式的名稱、被攔截函式所屬動態連結函式庫名稱及被攔截函式內之參數等相關資料；步驟二，撰寫一程式載入器並執行之，該載入器為一常駐於記憶體之程式，即，藉由該載入器之執行，會針對組態檔產生一攔截程式，該攔截程式內含程式碼和資料，而該載入器另可針對目標行程呼叫一載入函式庫(LoadLibrary)，該載入函式庫被載入器呼叫之後，加上一中斷點指令，此時，載入器可將攔截程式碼位址寫入目標行程的第一個頁(page)中，並且改變目標行程的EIP(Extended Instruction Pointer)暫存器；步驟三，設定好記憶體和暫存器之後，讓目標行程開始執行，目標行程會先執行載入器，然後觸及該步驟二所述之中斷點指令，該中斷點一被觸發，該目標行程就暫時被凍結，而使得該攔截程式獲得優先控制權，藉由於該攔截程式內，記錄了該目標行程中欲被攔截函式所屬各項資料(如被攔截函式名稱)，於是攔截程式恢復目標行程原定之執行流程(包括記憶體和暫存器)，攔截程式碼因此而被悄悄地載入目標行程中；步驟四，當目標行程執行過程中呼叫被攔截函式時，控制權先由攔截程式取得，而再由攔截程式將控制權交給原來目標行程想要呼叫的被攔截函式並執行之；步驟五，被攔截函式執行完後，控制權交還給攔截程式，藉由攔截程式呼叫一屬性設定函式，並藉由該屬性設定函式來修改IP標頭裡TOS欄位，最後將控制權回傳給目標行程，如此QLR即完成，目標行程所產生的封包也悄悄地被標註。 2.如申請專利範圍第1項所述之一種微軟視窗作業系統下具通透性之差異性服務封包標註方法，其中該被攔截函式之選定，依不同之目標行程函式內容而有所不同。 3.如申請專利範圍第1項所述之微軟視窗作業系統下具通透性之差異性服務封包標註方法，其中該攔截程式為一動態連結函式庫。 4.如申請專利範圍第1項所述之微軟視窗作業系統下具通透性之差異性服務標註封包方法，其中該目標行程為微軟視窗(Microsoft Windows)各系列作業系統之網際網路的應用程式。 5.如申請專利範圍第1項所述之微軟視窗作業系統下具通透性之差異性服務封包標註方法，其中該戴入器所呼叫之載入函式庫，係用來載入作業系統中動態連結的共享函式庫。 |
|
| 十一、圖式： | |
             |
|
瀏覽數:
分享