基于P2P的局域網多線程共享軟件設計論文
1 系統概述
本系統的主要功能其一，局域網下的文件P2P共享，這里包括文件的傳輸和文件列表的傳輸;其二，局域網下用戶的P2P心跳檢測。系統的特點是多線程多任務同步。
2 設計思想
下面將從兩個大模塊來介紹設計思路，首先是文件的收發，然后是文件列表的收發和心跳模塊，如圖1所示。
2.1 文件收發模塊
文件的收發是resource-shaie最基本的功能，也是最核心的功能。
2.1.1 有關文件收發的Socket的分類
因為這里采用的是TCP協議，所以在程序中，大體上存在于3組Socket，與文件收發有關，一組Socket是welcomesocket，用于監聽連接的到來，并Accept;另一組Socket，是數據傳輸的Socket，來自于welcomesocket的accept()，用于send文件數據給對等方，姑且稱作sendsocket;最后一組Socket也是數據傳輸的socket，通過connect()對等方的welcomesocket得到，與上面那個sendsocket是直接相連的，只是因為所面對的對象不同，對于當前對等方，因為這個Socket的用于recover文件，姑且稱作recvsocket。
可以這樣理解，對于一個對等方來說，sendsocket就只send()，recvsocket就只recover ()。之所以這樣分開，是為了方便管理，降低耦合度，使得兩個對等方之間的所直接相連的一對sendsocket和recvsocket在一個文件任務中維系關系，也就是說，一對socket，在同一時間只共同執行一個任務，一邊是發和一邊是收。然而，如果全在一個Socket中send和recv，就會變得很亂，一個socket就可能牽連多個任務，一個socket出了問題，可能幾個任務的收發都會失敗。
下面舉一個例子來具體說明為什么要這樣分類。
假使現在有兩個人，hana和alice。考慮hana從alice下載一個文件的情況，在不考慮上傳操作的時候，hana是主動的，alice是下載方，所以首先hana會connectalice的welcomesocket，而對于alice而言，她的welcomesocket一直在等待hana的接入，hana—旦發起連接她就會accept。接著，hana通過connect得到的socket就是所謂的recvsocket，而這個socket相對于alice，就是alice的sendsocket，她將從這個socket里接收數據，但是目前還不行，因為alice并不知道hana的要求是什么，所以這里需要向alice發送一個請求，同樣是通過recvsocket。對于alice而言，假使已經從welcome socket accept到了一個sendsocket，那么首先要獲取請求，她需要先對sendsocket執行一次recv請求的操作。
到這里，請求完成了，接下來，hana的recvsocket就不斷接收文件數據，alice的sendsocket不斷發送文件數據。反過來，假使alice想從hana那里下載東西，因為二人都有上述3組Socket，所以很容易實現。實際上，想實現上傳功能也可以用完全一樣的邏輯體系，只需要從后者發送一個特殊指令，使得前者發送一個下載請求給后者即可，如圖2所示。
2.1.2 文件請求的監聽和連接
上面討論的是純粹的傳輸一個文件的情況，下面內容逐漸復雜。
還是上面的例子，假設現在需要支持多任務的模式，也就是說，alice不僅僅要向hana—個人發送一個文件，而是將會向很多人發送文件，并且對于每個人，還不只是一個文件。
那么，alice可以開多個welcomesocket去listen，每一個welcomesocket監聽n個用戶，接著通過accept返回每一個文件的sendsocket，這樣一來，就等于說和每一個終端都建立起了多個傳送通道，每個傳送通道傳送一個文件，也就是一個任務。
現在問題是到底需要幾個這樣的welcomesocket?當然，可以只開一個welcome，全靠一個welcomesocket監聽(用戶數量)*(每個用戶的文件請求數量)數量的請求。但在實際設計中，使用了多個端口創建了多個welcomesocket，讓每一個welcomesocket對于每一個訪問他的終端而言，在單個任務執行的過程中，只能有一個文件的請求。這樣一來，每一個welcomesocket的最大并發連接數就一定是用戶的總數量，而welcomesocket的數量就是由alice能夠同時向一個終端send幾個文件決定的。
也就是說，hana在前一個下載任務執行完關閉recvsocket以前，不能向同一個welcomesocket再一次發起connect，(當然因為welcomesocket的實體是在alice那邊，所以hana在這里，實際上禁用了對于此welcomesocket的connect操作)這樣做的目的是為了限制對于同一個用戶的最大下載量。
所以，對于hana來說，假如她要從alice或者其他人那里下載多個文件，這就要求hana去connect那些用戶的多個welcomesocket，在connect中傳入的地址可能包涵每一個對象的IP和每一個傳輸port，所以hana的recvsocket最多可以和ip_num*port_num個數的sendsocket建立連接。(ip_num代表傳送端數量，一個ip—臺用戶，port_num代表在一個ip下對于單用戶支持的最大傳輸任務數量，那么，對于alice而言，
她最多同樣可以同時傳輸ip_num*port_num個任務)而在每一次任務完成之后，hana都會關閉掉那個任務的recvsocket，并且將這個任務所對應的welcomesocket的禁用狀態解除;與之對應的，alice在傳送完之后，也會將sendsocket關閉。
通過圖3來看這種情況，假使這次alice不僅要給hana發送文件，還要給自己的母親發送文件，對于hana或者alice的母親而言，最多同時從alice這里下載3個文件。
2.2 文件列表收發和心跳模塊
2.2.1 動態心跳檢測
前面說了P2P的文件傳輸機制，還講了多任務多用戶的情況，現在來說一下這個系統中的另一個很重要的機制，心跳機制。通過發送心跳信息和接收心跳，用來感知在局域網中，有哪些對等方是存在的，雙方的心跳包中有少量的數據，一般而言包含用戶的信息，比如用戶名，終端系統信息之類的。只有知道哪些對等方式存在的，才能進一步的保存這些對等文件通信中的有用信息，(可能包括這個用戶的文件列表，這個用戶的各個welcomesocket的地址，等)，最后根據這些信息才能真正地實現文件通信。
還是上面的那個例子，考慮了這樣情況，hana先上線了，過了一段時間alice才上線。那么在alice上線的那一瞬間，如何使得兩人都知道對方上線了呢，準確地說，是通過P2P軟件上線。這就好比兩臺機器都上了網，并且都登上了QQ，但QQ判斷是否上線，僅僅是有沒有在QQ上線，而不是在SKYPE上線了，所以我們應該有一套自己的機制，這就是要介紹的心跳機制。
在這里，機制是這樣實現的：不管對于hana或者alice，她們在上線的時候首先都會進行廣播式的連接嘗試，廣播對象是子網網段下所有的IP地址。其次，她們還會單獨為心跳建立一個welcomesocket，開一個監聽的線程專門用于監聽新上線用戶的connect請求。在這里，判斷是否在線的邏輯是 “收到某人的心跳包，就表示某人目前在線”。
在結合例子講解之前，先討論心跳機制中的socket分類。心跳的welcomesocket和文件傳輸的那個welcomesocket沒有什么性質上的區別，無非就是擁有自己獨特的端口號而已。但是，心跳的收發是沒有sendsocket和recvsocket的這種概念的，只有一個heartsocket，這個socket是一個專門用于心跳收發的長連接socket，他一直存在，不會被close的.，所以會被長期保存，這里要和之前說的用于文件傳輸的sendsocket和recvsocket區分，他們有很大的差異，首先，文件傳輸的send和recvsocket是不會長期保存的，一般只是一些函數中的局部變量，因為他經常改變，他傳完一個任務就關閉了，下一次又重新生成，所以文件傳輸中這些收發socket屬于短鏈接的socket，其次，在heartsocket中，發送和接收都是通過這一個socket。
舉—個例子，假設hana首先上線，她先開啟了心跳wel-comesocket的監聽，這時候，alice并沒有上線，所以有反饋，并且hana對子網內中所有ip的connect的嘗試也都失敗了。在這之后，alice上線了，首先alice的廣播式connect嘗試，成功激活了hana的welcomesocket的循環accept，成功連接之后，alice通過return的heartsocket，向hana發送一個心跳包，hana在accept之后會立馬recv這個心跳包，hana接收到心跳包之后，就認為alice目前處于在線了，他也可以通過心跳包里的信息知道來自于這個ip的人的名字叫alice，接著她要做的是就是把這個heartsocket保存好，準備下一次收發心跳包。那么流程到此，hana已經知道alice的存在了，但是alice卻還并不知道hana的存在，因為她還沒有接受到hana的心跳包。所以，hana在接收到alice的心跳包之后，保存了相關信息后，她還會通過這個heartsocket發送一個心跳包給alice，而對于alice而言，在她發送完心跳包之后，她會馬上recv對方的心跳包，這樣一來，就使得alice也知道了hana的存在了。
在相互都知道對方的存在之后，大家通過這同一個heartsocket相互發送和接收心跳包了，每接收一個心跳包就代表目前對方是存在的，一旦接受超時，那么就代表對方下線了，這樣就可以動態監測對方是否已經下線，如圖4所示。
2.2.2 文件列表的收發
下面來討論文件列表的收發。這個可以和之前的文件收發關聯起來，因為文件列表在一般情況下是不會有變動的，故而沒有必要一直重復接受對方的文件列表，僅僅是在第一次的時候和用戶自己認為需要更新的時候再去接收新的文件列表。所以，可以知道的是，文件列表的socket也是一種短連接的socket，用完了關閉就行了，需要的時候再connect對方的welcomesocket。
同樣，文件列表的傳輸是雙向的，所以在設計中，基本上和之前說到的文件傳輸機制如出一轍，也是3個socket，welcomesocket，recvsocket，sendsocket。只不過，請求文件列表的那個人不需要發送那個所謂“文件請求”而已，connect之后，直接從recvsocket中接收就可以了。
3 類設計思想
由于篇幅有限，只能做一下思想的概述。根據需求，類設計包括：user，myself_user，task，task_manager。結合面向對象的思想，其中有兩種類別，一種跟“用戶”有關，另一種跟“任務”有關。
在設計中，何為“用戶”，何為“任務”?具體概念，必須先弄清楚。用戶這個對象，指的是局域網中的對等方，也就是P2P中的peer，可以是自己的電腦，也可以是別人的電腦，這里還有一個myself_user的類，這個對象指的是本機用戶，并且是user的子類。任務則是指，對于自己電腦而言，每一個下載任務的實例，也就是說，你每一次向別的對等方請求一個文件，都會產生一個下載任務。
3.1 用戶有關類
User：用戶類的主要職能是保存peer的信息，包括ip、名字、welcomesocket的地址、heartsocket等。
Myself_user：作為user的子類，除了保存了普通用戶應有的信息之外，還要保存一些自身獨有的信息，以及為其他peer提供一些服務，包括有文件列表的傳輸服務，文件的傳輸服務。
世界就是圖5這樣的，進來的箭頭表示請求，從自己出去的箭頭表示反饋(也可以稱作“提供”)
user_manager：這個類字面上就可以理解是用戶管理器，主要職能就是動態監測用戶狀態。通過收發心跳包的手段來嗅探用戶狀態，然后更新用戶管理器中的用戶組，將不存在的刪除，新上線的添加。除此之外，他也和myself_user是相輔相成的，他初始化myself_user，并開啟myself_user的服務。所以在實際應用的時候，只需初始化user_manager，他就可以自己去初始化myself_user了。除此之外，文件列表的請求實際上也是從user_manager這里發送出去的，并且它也負責接受文件列表并更新某個user中所保存的文件列表。
3.2 任務有關類
Task：這個類代表了一個下載的任務信息的對象，包括任務名、對象ip、大小、已完成%，等。值得注意的是，它不僅能保存信息，真正的下載也要負責執行。從發送請求到接受文件，這些工作，一旦你run了這個任務，就會開始執行。
Task_manager：任務管理器類，它主要就是像用戶管理器那樣動態監測其中成員的狀態，其中有3個集合，running中的任務、success的任務、error的任務。主要職能是根據實時
4 結語
從展示的可執行的程序的截圖，程序在VS2013中調試沒有問題，也生成了release版本，界面是用coco2dx寫的，主要是考慮到可移植性，
【基于P2P的局域網多線程共享軟件設計論文】相關文章：
基于科技信息共享云服務機制研究論文11-02
個體知識共享研究:基于心理學的分析論文09-14
對共享單車論文03-17
共享單車的論文03-18
國外共享論文03-18
共享單車論文06-01