當采用這種模式時，即是所謂的完全點對點模式，此時每台計算機本身也是服務器，因為它需要進行 端口的偵聽。實現這個模式的難點是：各個主機（或終端）之間如何知道其它主機的存在？此時通常的做 法是當某一主機上線時，使用UDP協議進行一個廣播（Broadcast），通過這種方式來“告知”其它主機自 己已經在線並說明位置，收到廣播的主機發回一個應答，此時主機便知道其他主機的存在。這種方式我個 人並不喜歡，但在 C#編寫簡單的聊天程序 這篇文章中，我使用了這種模式，可惜的是我沒有實現廣播， 所以還很不完善。
第二種方式較好的解決了上面的問題，它引入了服務器，由這個服務器來專門進行廣播。服務器持續 保持對端口的偵聽狀態，每當有主機上線時，首先連接至服務器，服務器收到連接後，將該主機的位置（ 地址和端口號）發往其他在線主機（綠色箭頭標識）。這樣其他主機便知道該主機已上線，並知道其所在 位置，從而可以進行連接和對話。在服務器進行了廣播之後，因為各個主機已經知道了其他主機的位置， 因此主機之間的對話就不再通過服務器（黑色箭頭表示），而是直接進行連接。因此，使用這種模式時， 各個主機依然需要保持對端口的偵聽。在某台主機離線時，與登錄時的模式類似，服務器會收到通知，然 後轉告給其他的主機。
第三種模式是我覺得最簡單也最實用的一種，主機的登錄與離線與第二種模式相同。注意到每台主機 在上線時首先就與服務器建立了連接，那麼從主機A發往主機B發送消息，就可以通過這樣一條路徑，主機 A --> 服務器 --> 主機B，通過這種方式，各個主機不需要在對端口進行偵聽，而只需要服務器進 行偵聽就可以了，大大地簡化了開發。
而對於一些較大的文件，比如說圖片或者文件，如果想由主機A發往主機B，如果通過服務器進行傳輸 效率會比較低，此時可以臨時搭建一個主機A至主機B之間的連接，用於傳輸大文件。當文件傳輸結束之後 再關閉連接（桔紅色箭頭標識）。
除此以外，由於消息都經過服務器，所以服務器還可以緩存主機間的對話，即是說當主機A發往主機B 時，如果主機B已經離線，則服務器可以對消息進行緩存，當主機B下次連接到服務器時，服務器自動將緩 存的消息發給主機B。
本系列文章最後采用的即是此種模式，不過沒有實現過多復雜的功能。接下來我們的理論知識告一段 落，開始下一階段――漫長的編碼。
