張鐘

重慶理工大學 重慶 400054

0 前言

隨著Internet的普及，作為網(wǎng)絡通信的應用之一，網(wǎng)上聊天由于實時、快捷、方便，具有保護隱私的功能(私聊)，而受到了現(xiàn)代人的喜愛。我們通常使用的聊天程序，按實現(xiàn)的功能可分為公聊和私聊二大類，私聊亦簡稱為悄悄話。網(wǎng)上聊天時用得較多的是私聊。

在計算機網(wǎng)絡體系中，網(wǎng)絡體系一般可分為5層，從上到下，第1層是：應用層；第2層是：傳輸層；第3層是：網(wǎng)絡層；第4層是：鏈路層；第5層是：物理層。TCP協(xié)議位于其第2層的傳輸層中，TCP是可用于在不可靠的因特網(wǎng)上提供面向連接的、可靠的、有序的、無重復、全雙工端到端的字節(jié)流通信的協(xié)議，通信過程就像打電話一樣，可用于設計聊天室。在Windows系統(tǒng)中，對于Win32匯編語言而言，提供了WinSock API函數(shù)來支持TCP協(xié)議等，但在通信之前通信雙方必須先建立一個通信對象，這就是套接字Socket，而用于TCP的套接字是流套接字SOCK_STREAM，TCP協(xié)議的工作方式采用的是客戶端/服務器模式(Client/Server model)，另外，WinSock API函數(shù)提供的TCP套接字的使用模式有兩種：阻塞模式(同步模式)和非阻塞模式(異步模式)，創(chuàng)建一個套接字時，默認工作方式是阻塞模式，如需要使用非阻塞模式，則可用WSAAsyncSelect函數(shù)再設置為非阻塞模式。因此，客戶端和服務器端的通信套接字可以有四種工作方式組合：(1)客戶端阻塞模式<——>服務器端阻塞模式；(2)客戶端阻塞模式<——>服務器端非阻塞模式；(3)客戶端非阻塞模式<——>服務器端阻塞模式；(4)客戶端非阻塞模式<——>服務器端非阻塞模式。

1 聊天、私聊的實現(xiàn)思路

對于服務器端，當客戶端與服務器端連接上了后，服務器端就會創(chuàng)建一個服務線程與客戶端對應，接收客戶端發(fā)來的登錄數(shù)據(jù)包，其中包含有客戶名和密碼，服務器端將檢查每個客戶名和密碼，當?shù)卿浛蛻裘兔艽a與已登錄的客戶名和密碼都不同時，則存入客戶端信息鏈表中，并回應客戶端登錄成功，緊接著將所有在線客戶名信息發(fā)給客戶端；否則，回應客戶名或密碼相同，斷開連接。登錄成功后，服務線程將客戶信息放入消息隊列，供其它服務線程取出發(fā)往客戶端，告知某客戶進入了聊天室；同樣，當某客戶端退出時，服務線程也將該客戶信息放入消息隊列，讓其它服務線程取出發(fā)送到客戶端，告知某客戶離線了，同時刪除客戶端信息鏈表中該客戶端的客戶名和密碼；另外，服務器端還會實時列出所有在線的客戶名，實時監(jiān)視聊天內(nèi)容，對于不合適的聊天內(nèi)容給予刪除，實時跟蹤登錄和離線客戶人數(shù)和客戶名。服務器端每收到一條客戶端發(fā)來的聊天信息或登錄或退出信息，就對它進行編號，如第1條消息編號為1，第2條消息編號為2，……等等，然后放入消息隊列中，供各服務線程提取發(fā)往對應的客戶端，給消息編號在于方便各服務線程識別已發(fā)送過了的消息。每一個服務線程采用循環(huán)的方式，按消息的編號從小到大，從隊列中取出消息向自己的客戶端發(fā)送，如果已發(fā)送消息的編號大于消息隊列中的消息的最大編號，則表示隊列中的消息已發(fā)送完了，在發(fā)送消息的空閑時間，如客戶端有聊天信息到達，則暫停發(fā)送消息，優(yōu)先接收消息，并將消息放入消息隊列中，以供其它的服務線程提取并發(fā)向客戶端。此外，各服務線程在存、取消息隊列的消息時需要保持線程間的同步，以防出錯。

那么如何實現(xiàn)私聊呢？公聊時服務器端的服務線程從消息隊列中取出消息發(fā)送給客戶端就行了；而私聊則不同，它要求服務器端按指定的客戶名進行有選擇性的發(fā)送給客戶端。因此，可以在服務線程中增加一個私聊客戶名的檢查，因為私聊時，客戶端都會在上傳的聊天數(shù)據(jù)包里，私聊客戶名字段中，選定有私聊客戶名，因此，服務線程每次從隊列中取出一個聊天數(shù)據(jù)包時，總是把客戶端的客戶名(存儲在服務線程中的會話信息局部結構體變量中，放在局部變量中可方便分散管理)與聊天數(shù)據(jù)包中的私聊客戶名字段進行比較，如果相同，表示是私聊客戶，應將聊天信息發(fā)往指定的客戶端；否則，表示客戶端不是私聊客戶，不發(fā)送聊天信息，將聊天信息丟棄；如果聊天數(shù)據(jù)包中的私聊客戶名字段是0，表示這是公聊，聊天信息應發(fā)往所有客戶端(見圖1)。

對于客戶端，當與服務器端連接上后，立即發(fā)送登錄數(shù)據(jù)包，如果登錄回應數(shù)據(jù)包中字段dbResponse=0表示登錄成功，dbResponse=1表示客戶名或密碼與在線客戶相同，應重新選擇客戶名或密碼；登錄成功后，服務器端會將所有在線客戶名發(fā)給客戶端，客戶端把在線客戶名列出，以方便選擇私聊客戶；或當有客戶離線后，服務器端也會將離線客戶名發(fā)給客戶端，客戶端可實時將離線客戶名刪除，使客戶端與服務器端保持同步。當客戶端選擇公聊時，一次只須向服務器端發(fā)一個聊天數(shù)據(jù)包，并將上傳聊天數(shù)據(jù)包中的私聊客戶名字段賦0；當客戶端選擇私聊時，選擇了幾個私聊客戶名后，就循環(huán)發(fā)送幾個上行聊天數(shù)據(jù)包，每一個數(shù)據(jù)包，都包含了惟一一個私聊客戶名，在服務器端接收后，并判斷客戶名后，再轉發(fā)給對應的私聊客戶。

圖1 服務器端服務線程私聊實現(xiàn)流程圖(部分)

2 客戶端與服務器端通信雙方自定義的通信協(xié)議

由于TCP連接傳輸?shù)氖亲止?jié)流，對傳輸?shù)臄?shù)據(jù)不進行邊界保護，對數(shù)據(jù)包的發(fā)送可以組合或分割發(fā)送。因此，為了便于客戶端和服務器端能正確地接收和發(fā)送數(shù)據(jù)包，需要自定義通信雙方都能識別的數(shù)據(jù)包結構體和識別碼，其實識別碼就是數(shù)據(jù)包的標識，不同的數(shù)據(jù)包對應不同的識別碼。比如客戶端上傳的數(shù)據(jù)包有登錄數(shù)據(jù)包和聊天數(shù)據(jù)包，如果沒有對應的識別碼，那么服務器端就無法判斷所接收的數(shù)據(jù)包是聊天數(shù)據(jù)包還是登錄數(shù)據(jù)包，當然你可以選用其它的標志來標識各種數(shù)據(jù)包。每個數(shù)據(jù)包以定長數(shù)據(jù)包頭 + 可變長度的數(shù)據(jù)包體組成，每個聊天數(shù)據(jù)包的總長度填入數(shù)據(jù)包頭的數(shù)據(jù)包長度字段dwPacketLength中?？蛻舳?服務器端實際的接收和發(fā)送數(shù)據(jù)包的長度，就是依據(jù)數(shù)據(jù)包的長度字段dwPacketLength中的值執(zhí)行的。

; 聊天數(shù)據(jù)包，不等長數(shù)據(jù)包(上傳，客戶端——>服務器端)

3 服務器端服務線程自用的結構體

; 客戶端會話信息結構

4 總結

本文從網(wǎng)絡技術應用角度出發(fā)，介紹了聊天私聊的一種實現(xiàn)方法，用Win32匯編編程實現(xiàn)，并進行了測試，實現(xiàn)了聊天私聊的功能。由于篇幅的限制，所附程序代碼在此省略。另外，實現(xiàn)私聊還有幾種方法，比如說可將所有私聊用戶名和聊天信息一次上傳給服務器，再由服務器端逐個判斷后，再將聊天信息發(fā)往各指定的私聊客戶端等。

[1] 羅云彬編著. Windows環(huán)境下32位匯編語言程序設計(第2版).北京：電子工業(yè)出版社. 2006.

[2] 李媛媛編著.Visual C++網(wǎng)絡通信開發(fā)入門與編程實踐.北京：電子工業(yè)出版社.2008.