【正文】 ckets接口既能夠在單線程的Windows版本又能夠在占先的多線程Windows版本（Windows NT）中使用，在多線程環(huán)境中，套接口接口基本上是不變的。但多線程應用程序必須在線程之間同步對套接口的使用。這一點在其他形式的I/O中管理，例如文件I/O中是一樣的。如果沒有對套接口調(diào)用進行同步就會導致不可預測的結(jié)果。例如，如果有兩個線程同時調(diào)用同一套接口進行send()，那么數(shù)據(jù)發(fā)送的先后順序就無法保證了。在一個線程中關(guān)閉一個未完成的阻塞的套接口將會導致另一個線程使用同一套接口的阻塞調(diào)用出錯返回，就象操作被取消一樣。因此，采用多線程技術(shù)的同時，也必須解決好線程間的同步與通信問題。2． 線程之間的通信：通常情況下，一個次級線程要為主線程完成某種特定類型的任務，這就隱含著表示在主線程和次級線程之間需要建立一個通信的通道。系統(tǒng)采用使用事件對象和使用消息來完成這個任務。1）利用用戶定義的消息通信由于本應用程序的每一個線程它都擁有自己的消息隊列，這樣一來，就可以利用消息來傳遞信息而使得線程之間的通信易于實現(xiàn)。首先用戶要定義一個用戶消息，在使用時，向另外一個線程發(fā)送這個消息。下面的代碼是在線程結(jié)束時給出提示，使線程結(jié)束：UINT ThreadFunction(LPVOID pParam){while(!bend){Beep(100,100)。Sleep(1000)。}基于P2P 技術(shù)模式的民辦高校遠程教學系統(tǒng)及在線課堂軟件的研究與實現(xiàn)32：：PostMessage(hWnd,WM_USERMSG,0,0)；return 0。}WM_USERMSG消息的響應函數(shù)為：OnThreadended(WPARAM wParam,LPARAM lParam)LONG CTestView::OnThreadended(WPARAM wParam,LPARAM lParam){AfxMessageBox(Thread ended.)。Retrun 0。}以上是系統(tǒng)線程向用戶界面線程發(fā)送消息，對于工作者線程，如果它的設(shè)計模式也是消息驅(qū)動的，那么調(diào)用者可以向它發(fā)送初始化、退出、執(zhí)行某種特定的處理等消息，讓它在后臺完成。在控制函數(shù)中可以直接使用GetMessage()這個SDK函數(shù)進行消息分檢和處理，自己實現(xiàn)一個消息循環(huán)。GetMessage()函數(shù)在判斷該線程的消息隊列為空時，線程將系統(tǒng)分配給它的時間片讓給其它線程，不無效的占用CPU的時間，如果消息隊列不為空，就獲取這個消息，判斷這個消息的內(nèi)容并進行相應的處理。2）用事件對象實現(xiàn)通信在線程之間傳遞信號進行通信比較復雜的方法是使用事件對象，用MFC的Cevent類的對象來表示。事件對象處于兩種狀態(tài)之一：有信號和無信號，線程可以監(jiān)視處于有信號狀態(tài)的事件，以便在適當?shù)臅r候執(zhí)行對事件的操作。3．線程之間的同步各個線程可以訪問進程中的公共變量，所以使用多線程的過程中需要注意的問題是如何防止兩個或兩個以上的線程同時訪問同一個數(shù)據(jù)，以免破壞數(shù)據(jù)的完整性。保證各個線程可以在一起適當?shù)膮f(xié)調(diào)工作稱為線程之間的同步。前面一節(jié)闡述的事件對象實際上就是一種同步形式。Visual C++中使用同步類來解決操作系統(tǒng)的并行性而引起的數(shù)據(jù)不安全的問題，MFC支持的七個多線程的同步類可以分成兩大類：同步對象（CsyncObject、Csemaphore、Cmutex、CcriticalSection和Cevent）和同步訪問對象（CmultiLock和CsingleLock）。本課題使用下面的同步對象來使各個線程協(xié)調(diào)工作，使程序運行起來更加安全。1）使用臨界區(qū)對象：臨界區(qū)是保證在某一個時間只有一個線程可以訪問數(shù)據(jù)的方法。使用它的過程基于P2P 技術(shù)模式的民辦高校遠程教學系統(tǒng)及在線課堂軟件的研究與實現(xiàn)33中，需要給各個線程提供一個共享的臨界區(qū)對象，無論哪個線程占有臨界區(qū)對象，都可以訪問受到保護的數(shù)據(jù)，這時候其它的線程需要等待，直到該線程釋放臨界區(qū)對象為止。2）使用互斥對象：互斥與臨界區(qū)很相似，但是使用時相對復雜一些，它不僅可以在同一應用程序的線程間實現(xiàn)同步，還可以在不同的進程間實現(xiàn)同步，從而實現(xiàn)資源的安全共享。3）使用信號量對象：信號量的用法和互斥的用法很相似，但它實現(xiàn)計數(shù)處理。不同的是它可以同一時刻允許多個線程訪問同一個資源，創(chuàng)建一個信號量需要用Csemaphore類聲明一個對象，一旦創(chuàng)建了一個信號量對象，就可以用它來對資源的訪問技術(shù)。 通信模塊規(guī)劃由于系統(tǒng)通信技術(shù)的復雜性，本系統(tǒng)的實際開發(fā)分兩個階段。第一個階段開發(fā)測試版本，這個階段的主要任務，主要是解決通信技術(shù)問題，以把握P2P通信的流暢性、準確性。第二個階段則是功能開發(fā)為主，解決實時“在線課堂”的功能實現(xiàn)部分。在第一階段里，由于技術(shù)的底層性，我們將P2P通信的實現(xiàn)都以Visual C++二次開發(fā)類庫和基于COM的ActiveX控件的形式通過網(wǎng)上公布的方式提供給客戶。 程序模塊劃分本應用程序不論是從通信PC的功能角色（如中間服務器和子節(jié)點）來劃分，還是從程序模塊完成的功能（如發(fā)送方和接收方）來劃分，從實現(xiàn)機制的邏輯而言，其通信的完成都是基于C/S模型的請求與響應機制的，如下圖所示： C/S模型通信機制基于P2P 技術(shù)模式的民辦高校遠程教學系統(tǒng)及在線課堂軟件的研究與實現(xiàn)34為了不使混淆C/S模式下與P2P模式下的服務器（客戶機）概念，本文中對前者使用“中間服務器”與“子節(jié)點” 的稱呼，而對后者以“服務器”和“客戶方”稱呼。本應用程序邏輯模塊的劃分如下：客戶端連接請求模塊： C/S模式下，在子節(jié)點客戶方實現(xiàn)。處理客戶成為P2P網(wǎng)絡(luò)中合法的子節(jié)點的程序，對應的上層功能包括用戶的注冊、登錄連接等；服務器連接響應模塊： C/S模式下，在中間服務器端實現(xiàn)，處理客戶的連接請求，包括TCP方式的和UDP方式的；TCP服務器： C/S模式下，在中間服務器端實現(xiàn)，處理客戶TCP連接請求；UDP服務器： C/S模式下和P2P模式下均有實現(xiàn)。C/S模式下，在中間服務器端的實現(xiàn)部分響應客戶的UDP請求，負責動態(tài)維護客戶的身份認證和子節(jié)點之間的信息關(guān)聯(lián)，并不參與客戶信息的發(fā)送和接收；而在P2P模式下，則是基于“請求”和“響應”機制的對等服務器，負責對等P2P客戶的消息發(fā)送和接收；TCP客戶方：C/S模式下，在子節(jié)點實現(xiàn)，處理客戶方節(jié)點對成為P2P網(wǎng)絡(luò)節(jié)點的合法化請求；UDP客戶方：C/S模式下和P2P模式下均有實現(xiàn)。C/S模式下，處理子節(jié)點對中間服務器的UDP請求（不含客戶消息），P2P模式下，則完成對另一個P2P客戶的消息發(fā)送和接收，在這種模式下，客戶方與服務器方的角色是動態(tài)改變的，每一個子節(jié)點都具有相同的地位。．程序邏輯結(jié)構(gòu)圖由上節(jié)對程序邏輯結(jié)構(gòu)的劃分和描述，得到如下的程序邏輯結(jié)構(gòu)和程序通信機制示意圖如下：基于P2P 技術(shù)模式的民辦高校遠程教學系統(tǒng)及在線課堂軟件的研究與實現(xiàn)35 程序邏輯結(jié)構(gòu)示意圖程序通信機制如下圖： 程序?qū)崿F(xiàn)的通信機制示意圖基于P2P 技術(shù)模式的民辦高校遠程教學系統(tǒng)及在線課堂軟件的研究與實現(xiàn)36第四章 在線課堂P2P通信層技術(shù)實現(xiàn)在第三章，本文已對整個P2P系統(tǒng)的程序?qū)嵤┓桨浮⒔Y(jié)構(gòu)與設(shè)計原則進行了詳細的論述，因此本章不再贅述，而直接進入P2P通信技術(shù)的實現(xiàn)。 TCP Sockets通信的實現(xiàn) 窗口的選擇策略窗口的管理對P2P 數(shù)據(jù)傳送的效率有很大影響。窗口機制是本系統(tǒng)在TCP 數(shù)據(jù)報的重發(fā)機制中為了提高網(wǎng)絡(luò)帶寬利用率而引入的。TCP 中每個數(shù)據(jù)段都包括下一個希望接收到的序列號。在研究中我們發(fā)現(xiàn)，窗口比較大時會提高傳送速度，而如果傳送的數(shù)據(jù)超過窗口大小，數(shù)據(jù)會被拋棄。即使發(fā)送窗口大小為零，發(fā)送TCP 也必須做好準備接收數(shù)據(jù)并且可以發(fā)送至少一位新數(shù)據(jù)。即使接收窗口為零，發(fā)送方也會重發(fā)，重發(fā)的間隔時間一般為兩分鐘。如果一個P2P 的TCP 連接只有單向數(shù)據(jù)流，窗口信息可以在確認信息中得到，這些的序列號都是一個，因此沒法區(qū)別出誰先誰后。為此，本系統(tǒng)的采取下面的解決方案：當使用較少的大數(shù)據(jù)而要獲得高效率時分配非常小的窗口使數(shù)據(jù)以許多小段傳送。對于發(fā)送者來說要避免在發(fā)送小數(shù)據(jù)段時必須等到窗口大到一定程度再進行，以確認不被延時。接收窗口如果大小為零時，要傳送的數(shù)據(jù)段可能被分成越來越小的段。如果發(fā)送TCP 僅僅發(fā)送窗口允許大小的數(shù)據(jù)段，可能這些數(shù)據(jù)段會被換成比這個段大（或者?。┑臄?shù)據(jù)段發(fā)送。接收方時不時地進行窗口大小調(diào)整會使大數(shù)據(jù)段分為小段，而不成對。因此，系統(tǒng)盡量把小的窗口合成大的窗口，在系統(tǒng)中，對窗口采用動態(tài)的設(shè)置方式，即滑動窗口來實現(xiàn)。這將在下一節(jié)中論述。 字節(jié)順序的轉(zhuǎn)換在本系統(tǒng)中，任何基于Windows Sockets 函數(shù)對IP 地址和端口號的引用和傳送給Windows Sockets 函數(shù)的IP 地址和端口號均是按照網(wǎng)絡(luò)順序組織的，這也包括了sockaddr_in 結(jié)構(gòu)這一數(shù)據(jù)類型中的IP 地址域和端口域（但不包括sin_family 域）。但Intel 處理器和Internet 的字節(jié)順序是不同的，因此，為保證系統(tǒng)在其他的WindowsSockets 實現(xiàn)的主機字節(jié)順序與網(wǎng)絡(luò)字節(jié)順序相同的機器上運行，系統(tǒng)采取了字節(jié)順序的轉(zhuǎn)換措施。如果用戶輸入一個數(shù)，而且指定使用這一端口號，系統(tǒng)則在使用它建立地址以前，把它從主機順序轉(zhuǎn)換成網(wǎng)絡(luò)順序。相應地，當系統(tǒng)顯示包含于某一地址中的端口號（例如從getpeername()函數(shù)中返回的）時，這一端口號就在被顯示前從網(wǎng)絡(luò)順序轉(zhuǎn)換到主機順序?；赑2P 技術(shù)模式的民辦高校遠程教學系統(tǒng)及在線課堂軟件的研究與實現(xiàn)37 TCP 通信的實現(xiàn)流程對于系統(tǒng)中要精確傳輸?shù)腤indows Sockets 數(shù)據(jù)，采用流式套接字來實現(xiàn)。一方面，TCP 為兩臺主機提供了高可靠性的數(shù)據(jù)通信，它所做的工作只是把應用程序交給它的數(shù)據(jù)分成合適的小塊交給下面的網(wǎng)絡(luò)層，確認接收到的分組，設(shè)置發(fā)送最后確認分組的超時時鐘等。而由于傳輸層提供了高可靠性的端到端的通信，因此應用層可以忽略這些細節(jié)。但另一方面，TCP 提供這樣好的服務也是有代價的，由于它是基于握手連接的，需要更多的CPU 處理時間和網(wǎng)絡(luò)帶寬，服務器處理的請求也往往比較復雜，不是一來一去的請求應答所能解決的，而且往往是并發(fā)服務器。因此，TCP 模塊的復雜度也比UDP 大得多。發(fā)送TCP 消息使用流式套接口，面向連接使用面向連接的套接口編程，時序流程圖如下所示： TCP 連接的程序時序流程示意圖基于P2P 技術(shù)模式的民辦高校遠程教學系統(tǒng)及在線課堂軟件的研究與實現(xiàn)38流式套接口主要完成子節(jié)點與中間服務器的連接工作。工作流程大致如下：服務器首先啟動，通過調(diào)用socket()建立一個套接口（ SOCK_STREAM），然后調(diào)用bind()將該套接口和本地網(wǎng)絡(luò)地址聯(lián)系在一起，再調(diào)用listen()使套接口做好偵聽的準備，并規(guī)定它的請求隊列的長度，之后就調(diào)用accept()來接收連接?？蛻粼诮⑻捉涌诤缶涂烧{(diào)用connect()和服務器建立連接。連接一旦建立，客戶機和服務器之間就可以通過調(diào)用read()和write()來發(fā)送和接收數(shù)據(jù)。最后，待數(shù)據(jù)傳送結(jié)束后，雙方調(diào)用close()關(guān)閉套接口。 中間服務器的TCP 有效性設(shè)計 協(xié)議的選擇比較UDP 包和TCP 包的結(jié)構(gòu)，很明顯UDP 包不具備TCP 包復雜的可靠性與控制機制。與TCP 協(xié)議相同，UDP 的源端口數(shù)和目的端口數(shù)也都支持一臺主機上的多個應用。在本系統(tǒng)中，當強調(diào)傳輸性能而不是傳輸?shù)耐暾詴r，如：用戶級消息、音頻和多媒體應用，UDP 是最好的選擇。因為UDP 較低的開銷使其有更好的機會去傳送系統(tǒng)的管理數(shù)據(jù)，從而降低系統(tǒng)網(wǎng)絡(luò)的擁塞機率。但是，當數(shù)據(jù)傳輸?shù)男阅鼙仨氉屛挥跀?shù)據(jù)傳輸?shù)耐暾?、可控制性和可靠性時，TCP 協(xié)議則是當然的選擇。因此，本系統(tǒng)的中間服務器在用戶的最初連接中采取TCP方式，TCP 方式的握手機制可使本系統(tǒng)的中間服務器提供最高效率的可靠性。但另一方面，TCP 豐富的功能復雜的握手機制有時也會導致不可預料的性能低下。因此，系統(tǒng)一方面保持了TCP 通信的優(yōu)越性，另一方面對中間服務器的TCP 連接也進行了有效性的設(shè)計，以保證中間服務器的穩(wěn)定。 定時器與滑動窗口的動態(tài)設(shè)置方案1．問題的提出：定時器用于系統(tǒng)數(shù)據(jù)的重發(fā)機制中。系統(tǒng)TCP 的傳輸中設(shè)置有多個定時器，當一個包發(fā)送時，重發(fā)定時器開始計數(shù)；當收到確認信號后，重發(fā)定時器停止計數(shù)。如果超過設(shè)定時間段還沒有收到確認信號，就重發(fā)該包。但一個比較棘手的問題是：如果該段時間設(shè)置太長，那么當網(wǎng)絡(luò)傳輸錯誤增加時就將導致不必要的等待時間；如果太短，就會產(chǎn)生過多的重復包從而降低網(wǎng)絡(luò)的反應時間。從而，中間服務器的工作效率將大大降低。為解決這一矛盾，系統(tǒng)采取了如下方案。基于P2P 技術(shù)模式的民辦高校遠程教學系統(tǒng)及在線課堂軟件的研究與實現(xiàn)392．解決方案：為解決上述矛盾，系統(tǒng)采取持續(xù)定時器與滑動窗口的動態(tài)設(shè)置方案。滑動窗口的工作機制如下圖所示： 滑動窗口的動態(tài)設(shè)置示意圖在這一用例中，共有8 個幀處于待發(fā)送狀態(tài)，發(fā)送窗口值設(shè)置為5。當發(fā)送端發(fā)送0— 4 號幀后，如果持續(xù)定時器沒有檢測到回送的確認數(shù)據(jù)幀，就立即停止等待；如果收到確認幀，那么就對發(fā)送窗口值進行重新設(shè)置，使它沿順時針方向旋轉(zhuǎn)一個號，使窗口后沿再次與一個未被確認的幀號相鄰，這時5 號幀也落在了窗口之內(nèi)，就可以發(fā)送了。接下來，如果持續(xù)定時器又檢測到三個確認幀，那么發(fā)送窗口在次旋轉(zhuǎn)3 格，這樣就可以依次發(fā)送7 和0 號幀了。如果客戶端收到了一個大小為0 的窗口確認并且丟失了隨后的重發(fā)數(shù)據(jù)的