網(wǎng)絡(luò)聊天程序的三種模式

實現(xiàn)一個網(wǎng)絡(luò)聊天程序本應(yīng)是最后一篇文章的內(nèi)容，也是本系列最后的一個程序，來作為一個終結(jié)。但是我想后面更多的是編碼，講述的內(nèi)容應(yīng)該不會太多，所以還是把講述的東西都放到這里吧。

當采用這種模式時，即是所謂的完全點對點模式，此時每臺計算機本身也是服務(wù)器，因為它需要進行端口的偵聽。實現(xiàn)這個模式的難點是：各個主機（或終端）之間如何知道其它主機的存在？此時通常的做法是當某一主機上線時，使用UDP協(xié)議進行一個廣播（Broadcast），通過這種方式來“告知”其它主機自己已經(jīng)在線并說明位置，收到廣播的主機發(fā)回一個應(yīng)答，此時主機便知道其他主機的存在。這種方式我個人并不喜歡，但在 C#編寫簡單的聊天程序 這篇文章中，我使用了這種模式，可惜的是我沒有實現(xiàn)廣播，所以還很不完善。

?第二種方式較好的解決了上面的問題，它引入了服務(wù)器，由這個服務(wù)器來專門進行廣播。服務(wù)器持續(xù)保持對端口的偵聽狀態(tài)，每當有主機上線時，首先連接至服務(wù)器，服務(wù)器收到連接后，將該主機的位置（地址和端口號）發(fā)往其他在線主機（綠色箭頭標識）。這樣其他主機便知道該主機已上線，并知道其所在位置，從而可以進行連接和對話。在服務(wù)器進行了廣播之后，因為各個主機已經(jīng)知道了其他主機的位置，因此主機之間的對話就不再通過服務(wù)器（黑色箭頭表示），而是直接進行連接。因此，使用這種模式時，各個主機依然需要保持對端口的偵聽。在某臺主機離線時，與登錄時的模式類似，服務(wù)器會收到通知，然后轉(zhuǎn)告給其他的主機。

第三種模式是我覺得最簡單也最實用的一種，主機的登錄與離線與第二種模式相同。注意到每臺主機在上線時首先就與服務(wù)器建立了連接，那么從主機A發(fā)往主機B發(fā)送消息，就可以通過這樣一條路徑，主機A --> 服務(wù)器 --> 主機B，通過這種方式，各個主機不需要在對端口進行偵聽，而只需要服務(wù)器進行偵聽就可以了，大大地簡化了開發(fā)。

而對于一些較大的文件，比如說圖片或者文件，如果想由主機A發(fā)往主機B，如果通過服務(wù)器進行傳輸效率會比較低，此時可以臨時搭建一個主機A至主機B之間的連接，用于傳輸大文件。當文件傳輸結(jié)束之后再關(guān)閉連接（桔紅色箭頭標識）。

除此以外，由于消息都經(jīng)過服務(wù)器，所以服務(wù)器還可以緩存主機間的對話，即是說當主機A發(fā)往主機B時，如果主機B已經(jīng)離線，則服務(wù)器可以對消息進行緩存，當主機B下次連接到服務(wù)器時，服務(wù)器自動將緩存的消息發(fā)給主機B。

本系列文章最后采用的即是此種模式，不過沒有實現(xiàn)過多復(fù)雜的功能。接下來我們的理論知識告一段落，開始下一階段――漫長的編碼。