【文章內(nèi)容簡(jiǎn)介】 注冊(cè)的信息發(fā)送給服務(wù)器處理，若注冊(cè)成功，用戶會(huì)得到一個(gè)iM帳號(hào)。（3）創(chuàng)建IM群：在客戶端下，iM會(huì)員可以創(chuàng)建多個(gè)iM群，客戶端將待創(chuàng)建的信息發(fā)送給服務(wù)器，服務(wù)器返回創(chuàng)建信息。若創(chuàng)建成功，客戶端能獲得一個(gè)唯一的iM群號(hào)。（4）添加好友：iM會(huì)員能夠添加其他用戶為好友，通過對(duì)該用戶發(fā)送添加請(qǐng)求，若該會(huì)員統(tǒng)一添加，兩會(huì)員便成為好友，更新好友列表，可以進(jìn)行好友間的功能。（5）加入群：iM會(huì)員可以選擇加入任意的iM群，客戶端會(huì)發(fā)送請(qǐng)求給該群的管理員進(jìn)行驗(yàn)證，若驗(yàn)證通過，該會(huì)員便成為該群的一員，并更新群成員列表。（6）文件傳輸：好友與好友之間可以任意互相傳輸文件，并且同時(shí)支持多個(gè)文件的高速傳輸。（7）好友聊天：好友與好友之間可以進(jìn)行基于文本的文字聊天。（8）群聊天：好友能在自己所加的群里，進(jìn)行群聊天，其它人在群里的任何對(duì)話均能被接受到。（9）退出登陸：iM會(huì)員退出登陸時(shí)將發(fā)送命令給服務(wù)器，服務(wù)器獲得退出命令后將更新在線列表，并通知所有該會(huì)員的好友，更新他們的好友在線列表。（10）查詢會(huì)員或群信息：iM會(huì)員可以通過查詢界面，查詢指定會(huì)員或群的信息。（11）UDP打洞請(qǐng)求：客戶端無法與另一客戶端進(jìn)行UDP通訊時(shí)，將向服務(wù)器發(fā)送打洞請(qǐng)求。服務(wù)器將打洞的結(jié)果返回給客戶端。（12）更改會(huì)員資料：可以更新自己的基本信息。（13）心跳功能：在線的客戶端能定期的向服務(wù)器發(fā)送心跳命令，避免非正常結(jié)束iMessaging后導(dǎo)致的非法的登出。1．基于UDP的數(shù)據(jù)發(fā)送與接收（1）服務(wù)器端的數(shù)據(jù)接收服務(wù)器基于UDP的數(shù)據(jù)發(fā)送與接受主要采用的是MFC提供的CAsyncSocket類，該類提供了基于異步非阻塞式的IO操作。iMessaging程序里根據(jù)CAsyncSocket派生了一個(gè)CIMSocket類，服務(wù)器用該類進(jìn)行數(shù)據(jù)的發(fā)送與接收，并將接收后的數(shù)據(jù)按照命令類型分發(fā)給各處理子模塊。創(chuàng)建該類在CIMessageDlg對(duì)話框類（服務(wù)器運(yùn)行的主窗口）的OnInitDialog函數(shù)里，每當(dāng)程序運(yùn)行時(shí)都將自動(dòng)調(diào)用該函數(shù)，進(jìn)行對(duì)話框的初始化操作，這是將是創(chuàng)建CIMSocket類的最佳場(chǎng)所。該對(duì)話框類提供一個(gè)內(nèi)部接口函數(shù)BOOL CIMessageDlg::CreateUDPSocket()，用于創(chuàng)建CIMSocket類。當(dāng)CIMSocket類創(chuàng)建成功后，將其指針保存在對(duì)話框里保護(hù)類型成員變量里CIMSocket* m_pSocket，方便以后的使用。CIMSocket類重載了虛函數(shù)OnReceive用來接收網(wǎng)絡(luò)信息，該函數(shù)是一個(gè)系統(tǒng)自動(dòng)調(diào)用的消息相應(yīng)函數(shù)，每當(dāng)系統(tǒng)發(fā)現(xiàn)該套接字的接收緩沖區(qū)里有數(shù)據(jù)的時(shí)候，將調(diào)用該函數(shù)，那么我們就可以在該函數(shù)里，調(diào)用RecvFrom或Recv來獲取數(shù)據(jù)。由于正是考慮到基于命令的信息傳輸，接收緩沖區(qū)里不一定時(shí)刻都有數(shù)據(jù)到來，那么采用了基于消息響應(yīng)的異步套接字類。在OnRecevie函數(shù)里，可能同時(shí)會(huì)有多個(gè)數(shù)據(jù)包到來，若按照每到一個(gè)數(shù)據(jù)包進(jìn)行解析和分發(fā)，將可能延誤整個(gè)接收處理過程，造成接收緩沖區(qū)溢出，丟失大量數(shù)據(jù)包，因此iMessaging在處理接收來的數(shù)據(jù)時(shí)，會(huì)先將接收到的數(shù)據(jù)包加入到一個(gè)數(shù)據(jù)包隊(duì)列里面去，用另一個(gè)獨(dú)立的接收線程讀取該隊(duì)列里的數(shù)據(jù)包，再根據(jù)其命令類型分發(fā)處理（在iMessaging里封裝了一個(gè)CPacket類，用來存儲(chǔ)各種接收到的數(shù)據(jù)包）。在接收線程里（），會(huì)不斷的判斷數(shù)據(jù)包隊(duì)列里是否有數(shù)據(jù)到來，若沒有數(shù)據(jù)，則進(jìn)入等待（iMessaging里使用的時(shí)事件內(nèi)核對(duì)象，當(dāng)現(xiàn)在數(shù)據(jù)包隊(duì)列里沒有任何數(shù)據(jù)時(shí)進(jìn)入睡眠狀態(tài)，這樣可以降低該線程因反復(fù)執(zhí)行判斷循環(huán)而造成占用大量CPU時(shí)候，當(dāng)OnRecevie里接收到一個(gè)數(shù)據(jù)后，就會(huì)將觸發(fā)事件對(duì)象，喚醒接收線程）。若發(fā)現(xiàn)有數(shù)據(jù)到來，則分析數(shù)據(jù)包類型，創(chuàng)建相關(guān)的處理線程執(zhí)行相關(guān)的處理操作，這樣可以在同一時(shí)間同時(shí)處理多個(gè)任務(wù)請(qǐng)求，提高了服務(wù)器的工作效率。程序執(zhí)行流程圖如下： （服務(wù)器端）（2）客戶機(jī)端的數(shù)據(jù)接收客戶端的接收流程與服務(wù)器大致相同，同樣將UDP發(fā)送與接收封裝到一個(gè)CIMSocket類里（這個(gè)類與前面的CIMSocket不是同一個(gè)）。在程序啟動(dòng)后同樣會(huì)在OnInitDialog里調(diào)用一個(gè)原型為BOOL CIMessagingDlg::CreateSocket(CString szIP, UINT16 nPort)的函數(shù)創(chuàng)建CIMSocket對(duì)象，接收原理與服務(wù)器接收相同，同樣要提供一個(gè)數(shù)據(jù)包隊(duì)列，同樣要單獨(dú)創(chuàng)建一個(gè)接收線程進(jìn)行數(shù)據(jù)包的解析與分發(fā)，唯一不同的是處理后的數(shù)據(jù)包并不單獨(dú)創(chuàng)建線程進(jìn)行處理，而是通過發(fā)送消息，將處理分發(fā)到各對(duì)應(yīng)的對(duì)話框里，自行處理。因?yàn)榭蛻舳酥饕筛鞣N類型的窗口構(gòu)成，而窗口本身就是一個(gè)線程，因此不會(huì)阻塞到接收線程的正常運(yùn)行。（）（客戶端）（3）服務(wù)器端的數(shù)據(jù)發(fā)送服務(wù)器端的數(shù)據(jù)發(fā)送相對(duì)比較簡(jiǎn)單，除了在獲取好友列表和群成員時(shí)是基于TCP協(xié)議的數(shù)據(jù)傳輸，其余的均是基于UDP協(xié)議。因此在CIMSockt類中封裝了一個(gè)int CIMSocket::SendToClient(CPacketamp。 packet)成員函數(shù)，在需要發(fā)送數(shù)據(jù)的時(shí)候（服務(wù)器端大多在處理線程里回復(fù)數(shù)據(jù)給客戶端）直接調(diào)用該公共成員函數(shù)即可。（4）客戶機(jī)端的數(shù)據(jù)發(fā)送客戶端的數(shù)據(jù)發(fā)送相對(duì)于服務(wù)器端稍微要復(fù)雜一點(diǎn)。這是因?yàn)榭蛻舳瞬粌H需要發(fā)送給服務(wù)器，還要處理發(fā)送給其他客戶端的情況，特別是在發(fā)送給客戶端的時(shí)候，若在廣域網(wǎng)環(huán)境下還要進(jìn)行PING驗(yàn)證，若PING失敗還需要向服務(wù)器申請(qǐng)打洞服務(wù)?？蛻舳说腃IMSocket提供了兩個(gè)成員函數(shù)來進(jìn)行數(shù)據(jù)發(fā)送，一個(gè)是用來向服務(wù)器發(fā)送數(shù)據(jù)，函數(shù)原型為BOOL CIMSocket::Send Info(void *lpData, int nBufLen)。另一個(gè)用來向其它客戶端發(fā)送數(shù)據(jù)，函數(shù)原型為BOOL CIMSocket::SendToFriend(void *lpData, int nBufLen, DWORD nAddr, UINT nPort)。特別說明一下，文件傳輸?shù)墓δ懿]有封裝在CIMSocket里，它并不支持基于UDP的文件傳輸。2．TCP連接為了保證數(shù)據(jù)的可靠性，對(duì)于連續(xù)發(fā)送大量有序的數(shù)據(jù)包，采用UDP協(xié)議并不保險(xiǎn)，因此在必要的時(shí)候，也必須采用TCP協(xié)議來支持?jǐn)?shù)據(jù)的穩(wěn)定和可靠性。在iMessaing里，由于獲取好友列表或獲取群成員時(shí)會(huì)連續(xù)發(fā)送大量的數(shù)據(jù)，因此此時(shí)最好使用TCP協(xié)議進(jìn)行數(shù)據(jù)通信。 TCP接收請(qǐng)求處理流程圖（服務(wù)器端）在服務(wù)器端，iMessaging同樣是在主窗口的OnInitDialog里創(chuàng)建TCP連接，同樣提供了一個(gè)內(nèi)部接口函數(shù)BOOL CIMessageDlg::CreateTCPSocket()來創(chuàng)建TCP連接。由于有兩種情況需要用到TCP連接，因此分別設(shè)計(jì)了BOOL CreateTcpSocketToGetLoginUserInfo()和BOOL CreateTcpSocketToGetGroupMemberInfo()這兩個(gè)函數(shù)完成對(duì)應(yīng)的TCP創(chuàng)建工作。由于考慮到同時(shí)將會(huì)有多個(gè)獲取好友列表或群成員列表的請(qǐng)求，為了提高服務(wù)器的響應(yīng)速度，也應(yīng)該為獲取好友列表和群成員分別創(chuàng)建一個(gè)線程來accept客戶端的請(qǐng)求連接。為了充分發(fā)揮多服務(wù)器多CPU的特點(diǎn)，在accept請(qǐng)求后服務(wù)器會(huì)創(chuàng)建一個(gè)線程池來管理每個(gè)處理線程，線程池的最大線程數(shù)應(yīng)該等于CPU的個(gè)數(shù)，這個(gè)是基于最大化提高CPU處理效率的特點(diǎn)而確定的，這是因?yàn)樯僖粋€(gè)線程，不能發(fā)揮到所有CPU的并發(fā)優(yōu)勢(shì)，若多一個(gè)線程，同樣會(huì)等待CPU時(shí)間片，所以沒有必要。當(dāng)處理線程執(zhí)行結(jié)束后，不應(yīng)該立即退出，這樣會(huì)由于反復(fù)創(chuàng)建和銷毀線程而浪費(fèi)大量的CPU時(shí)間和資源。正確的做法應(yīng)該在完成處理后，查詢當(dāng)前是否有TCP連接請(qǐng)求未處理，若有就讀取該請(qǐng)求數(shù)據(jù)進(jìn)行處理，這樣就避免了銷毀和創(chuàng)建線程時(shí)浪費(fèi)的時(shí)間，這個(gè)思想是基于完成端口的內(nèi)部實(shí)現(xiàn)原理而設(shè)計(jì)的。 TCP接收處理線程執(zhí)行流程圖（服務(wù)器端）iMessaing的會(huì)員登陸采用了UDP和TCP相結(jié)合的方式，涉及到地的對(duì)話框切換較多，登陸過程較為復(fù)雜。用戶輸入帳號(hào)和密碼，點(diǎn)擊登陸后，會(huì)響應(yīng)CIMessagingDlg主窗口的OnLogin函數(shù)，該函數(shù)里創(chuàng)建了一個(gè)登陸對(duì)話框CIMLoginedDlg，該對(duì)話框主要起到一個(gè)會(huì)員登陸，并獲取登陸信息的作用。創(chuàng)建該對(duì)話框1秒之后，會(huì)開始向服務(wù)器發(fā)送會(huì)員驗(yàn)證包，iMessaing定義的命令包主要采用結(jié)構(gòu)體的方式，每一個(gè)命令包都含有一個(gè)命名包頭和命令包數(shù)據(jù)，其中頭部被定義為：struct IM_Header{UINT32 cmd。UINT16 seg。UINT16 id。UNT32 reserved。}該結(jié)構(gòu)體的cmd字段便是命令，所有的命令被定義為宏。其中會(huì)員登陸的命令為IM_LOGIN，其值為0x0001，其他的命令將在后面會(huì)提到。登陸所發(fā)送的數(shù)據(jù)包被定義為了一個(gè)名為login_info的結(jié)構(gòu)體（），該結(jié)構(gòu)體除了包含命令頭部外，還包含了待登陸的賬號(hào)和密碼?？蛻舳税l(fā)送了會(huì)員登陸命令后，便等待服務(wù)器的回應(yīng)了，若等待超時(shí)便提示連接失敗。在服務(wù)器部分，通過前面描述的udp的接收流程，服務(wù)器在接收到登陸請(qǐng)求后，最終會(huì)創(chuàng)建一個(gè)LoginThread線程來進(jìn)行登陸驗(yàn)證。在該線程中服務(wù)器首先讀取數(shù)據(jù)庫(kù)進(jìn)行驗(yàn)證，所有的數(shù)據(jù)庫(kù)操作被封裝到了CSql類里，該類提供了一個(gè)公用方法，Excute，具體用法見代碼。驗(yàn)證后將返回信息給客戶端，在iMessaging里，幾乎所有由server回應(yīng)給客戶端的數(shù)據(jù)包結(jié)構(gòu)體被定義為XXX_back的名字，如登陸回應(yīng)，用到了login_back結(jié)構(gòu)體。若服務(wù)器發(fā)現(xiàn)驗(yàn)證成功，并且當(dāng)前該會(huì)員沒有在其他處登陸過，那么就通知該會(huì)員所有的在線好友的上線通知，這里調(diào)用了CIMSocket::NotifyMember函數(shù)。當(dāng)服務(wù)器執(zhí)行完登陸處理線程后，客戶端進(jìn)入接收流程，若驗(yàn)證失敗，根據(jù)錯(cuò)誤信息進(jìn)行錯(cuò)誤提示，若發(fā)現(xiàn)驗(yàn)證成功，便開始獲取登陸信息。iMessaging在獲取好友列表和群列表的時(shí)候用到了TCP短連接，客戶端會(huì)創(chuàng)建一個(gè)RecvInfoThread線程去接收數(shù)據(jù)，在線程內(nèi)部會(huì)創(chuàng)建 TCP套接字連接服務(wù)器，并依次獲取群信息和好友信息。iMessaging在獲取好友信息時(shí)并不是全部獲取，除非是該計(jì)算機(jī)第一次登陸該賬號(hào)，因?yàn)樵诘顷懞?，客戶端?huì)將登陸信息記錄在文件里，下次本機(jī)登陸時(shí)就可以直接從文件中獲取，加快登陸速度。在獲取完登陸信息后，將好友信息和群信息分別添加到g_fredAllList和 g_groupList鏈表里，隨后便創(chuàng)建登陸后的用戶界面CIMLogonDlg對(duì)話框。在初始化該對(duì)話框時(shí)，會(huì)將之前獲取的信息加入到兩個(gè)CIMListCtrl里面（登陸界面的列表控件），隨后會(huì)向服務(wù)器發(fā)送離線消息請(qǐng)求，服務(wù)器接收到消息后，會(huì)將保存在數(shù)據(jù)庫(kù)里的離線消息發(fā)送給該會(huì)員。當(dāng)客戶端接收完離線消息后，登陸過程完畢。在添加好友和加入群功能實(shí)現(xiàn)都大同小異，其中服務(wù)器起到了中間紐帶的作用。其主要用到了add_friends_info命令數(shù)據(jù)包，命令為IM_ADD_FRIENDS。其次，該結(jié)構(gòu)含有一個(gè)子命令字段sub_cmd，表示現(xiàn)在發(fā)送到服務(wù)器端的命令時(shí)請(qǐng)求，還是通知回復(fù)。添加好友被大致分為請(qǐng)求和通知回應(yīng)兩個(gè)階段，如上圖所示，上面部分就是添加好友的請(qǐng)求階段，下面部門就是通知回應(yīng)階段?？蛻舳讼雀鶕?jù)待加好友特征查詢好友信息，若有該好友，客戶端可以選擇添加該好友，隨后，客戶端會(huì)發(fā)送一個(gè)add_friends_info的數(shù)據(jù)包給服務(wù)器，當(dāng)服務(wù)器接收到該請(qǐng)求后，便進(jìn)入AddFriends線程進(jìn)行處理，首先服務(wù)器會(huì)驗(yàn)證該好友是否在線，若不在線，便發(fā)送離線請(qǐng)求（保存在離線消息數(shù)據(jù)庫(kù)里），若在線，將立即發(fā)送請(qǐng)求給待加好友。這個(gè)過程就是添加好友的請(qǐng)求階段。當(dāng)待加好友的客戶端接到好友申請(qǐng)后，用戶可以選擇同意或者拒絕，隨后又將回復(fù)的信息發(fā)送給服務(wù)器，讓服務(wù)器來回復(fù)起初申請(qǐng)?zhí)砑雍糜训目蛻舳?。此時(shí)，服務(wù)器仍然調(diào)用了AddFriends線程進(jìn)行回應(yīng)申請(qǐng)者，同樣要先驗(yàn)證是否在線，若在線便將信息發(fā)送回申請(qǐng)者。若對(duì)方同意了，兩方客戶端都均更新好友列表，同時(shí)服務(wù)器要更新好友關(guān)系表里的內(nèi)容。加入群的流程與添加好友的流程大致一樣，唯一的區(qū)別是服務(wù)器在處理過程中創(chuàng)建JoinGroup線程來處理，在發(fā)送申請(qǐng)數(shù)據(jù)包的過程中，需要在數(shù)據(jù)庫(kù)中查詢?nèi)旱墓芾韱T，將申請(qǐng)轉(zhuǎn)發(fā)給管理員。在系統(tǒng)實(shí)現(xiàn)技術(shù)章節(jié)介紹了基于UDP的文件傳輸?shù)拇蟾诺脑O(shè)計(jì)思想，現(xiàn)在就全面分析下在iMessaging里是如何實(shí)現(xiàn)基于多個(gè)任務(wù)的UDP文件傳輸。在iMessaging里，實(shí)現(xiàn)UDP文件傳輸?shù)暮诵拇a封裝到了CFiletransPageItem類里，該類實(shí)際上是一個(gè)chlid類型的面板對(duì)話框，依附在CSendFilePage類上。當(dāng)客戶端選擇發(fā)送文件請(qǐng)求后，將立即創(chuàng)建該類，同時(shí)會(huì)在對(duì)話框初始化代碼部分創(chuàng)建一個(gè)基于UDP的套接字，用于文件傳輸，該套接字的收發(fā)封裝到CIMUdpSendFileSocket類里，并采用阻塞式的IO模型。接著，客戶端會(huì)將文件名，文件大小和文件分塊數(shù)以及自己的ID號(hào)和剛創(chuàng)建的端口號(hào)填入send_file_request_info結(jié)構(gòu)體里，其中頭命令為IM_SEND_FILE_REQUEST_INFO，隨后用CIMSocket對(duì)象來發(fā)送該請(qǐng)求。接收請(qǐng)求的客戶端收到命令后，會(huì)創(chuàng)建一個(gè)CFiletransPageItem對(duì)象進(jìn)行文件傳輸，同時(shí)也創(chuàng)建一個(gè)專門用于該任務(wù)的套接字。若用戶作了回應(yīng)行為，在CFiletransPageItem類中，就會(huì)發(fā)送send_file_request_info_back命令（同樣用CIMSocket對(duì)象發(fā)送）通知請(qǐng)求方是否開始文件傳輸。文件傳輸開始后，所有關(guān)于該文件的數(shù)據(jù)傳輸都發(fā)生在該CFiletransPageItem對(duì)象和CIMUdpSendFileSocket對(duì)象里。CIMUdpSendFileSocket對(duì)象負(fù)責(zé)數(shù)據(jù)的接收和發(fā)送，CFiletransPageItem對(duì)象負(fù)責(zé)UDP文件傳輸?shù)乃惴ê徒缑娌僮?。發(fā)送方會(huì)創(chuàng)建一個(gè)名為FileTransferThread的發(fā)送線