Author: Fox
在以前寫
MMORPG中游戲世界的構(gòu)建
時，提到服務(wù)器架構(gòu)的分類。大多數(shù)情況下，每一種不同的服務(wù)器只會與其對應(yīng)的一個服務(wù)器和多個客戶端通信。比如，GameServer(GS)只會與WorldServer(WS)通信，也就是說GS只作為WS的客戶端。這次，由于項(xiàng)目需求，新增加了一個SomeServer(SS)作為GS的服務(wù)器。
一、SS網(wǎng)絡(luò)連接分析
由于需要和大量GS建立網(wǎng)絡(luò)連接，所以SS使用了IOCP模型。鑒于
上一次寫IOCP
時遭到
Kevin
TX的鄙視，所以決定今天多寫一點(diǎn)。SS的網(wǎng)絡(luò)模型大致如下：
0、服務(wù)器主線程啟動；
1、初始化Winsock，SDK func: WSAStartup ()；
2、創(chuàng)建一個使用overlapped I/O的socket，SDK func: WSASocket()；
3、綁定端口，將本地地址與創(chuàng)建的socket關(guān)聯(lián)起來，SDK func: bind()；
4、創(chuàng)建IOCP對象，SDK func: CreateIoCompletionPort()；
5、創(chuàng)建工作者線程，CreateWorkerThreads()；
6、開始監(jiān)聽，SDK func: listen()；
7、接受客戶端連接，SDK func: WSAAccept()；
8、當(dāng)有新的連接請求到達(dá)時，將WSAAccept返回的對應(yīng)的客戶端socket關(guān)聯(lián)到IOCP；
9、處理WSASend() or WSARecv()。
在實(shí)際處理時，可能會根據(jù)需要建立額外的線程處理socketopt命令，甚至建立專門處理WSAccept的線程。
關(guān)于工作者線程WorkerThread：
通過GetQueuedCompletionStatus()，獲取I/O類型和對應(yīng)的socket，如果為接收則通知接收完成并繼續(xù)新的WSARecv()，如果為發(fā)送則通知發(fā)送完成。
二、GS網(wǎng)絡(luò)連接分析
GS上對于SS客戶端采用的是WSAEventSelect模型，通過網(wǎng)絡(luò)事件觸發(fā)相應(yīng)操作。
0、服務(wù)器主線程啟動；
1、初始化Winsock，SDK func: WSAStartup ()；
2、創(chuàng)建一個使用overlapped I/O的socket，SDK func: WSASocket()；
4、綁定端口，將本地地址與創(chuàng)建的socket關(guān)聯(lián)起來，SDK func: bind()；
5、創(chuàng)建網(wǎng)絡(luò)事件，SDK func: CreateEvent()；
6、設(shè)置網(wǎng)絡(luò)事件的響應(yīng)，SDK func: WSAEventSelect()；
7、等待網(wǎng)絡(luò)事件，SDK func: WSAWaitForMultipleEvents()；
8、分析網(wǎng)絡(luò)事件類型并處理，SDK func: WSAEnumNetworkEvents()。
這里之所以采用CreateEvent而不是WSACreateEvent，是因?yàn)橛蒀reateEvent創(chuàng)建的事件允許為auto reset的，而WSACreateEvent創(chuàng)建的事件是manually reset的。
三、實(shí)現(xiàn)過程中的小插曲
在GS的客戶端實(shí)現(xiàn)中遇到幾個問題。
首先是在消息處理上，GS發(fā)到SS的消息，SS并沒有完全接受到，而SS發(fā)送到GS的消息一切正常。后來跟了一下SS消息隊(duì)列，發(fā)現(xiàn)SS居然可以收到GS發(fā)送到WS的消息！然后就在GS上找原因，原來是WS在和SS共用消息隊(duì)列，以前GS只對應(yīng)一個服務(wù)器，無所謂共用。現(xiàn)在加了SS，自然要分開處理，否則WS和SS都可能收到發(fā)給對方的消息。
后面一個bug從周一開始已經(jīng)強(qiáng)奸了我四天了。即使SS已經(jīng)關(guān)閉，WSAEnumNetworkEvents返回的事件對應(yīng)FD_CONNECT的iErrorCode值始終為0。因?yàn)橹虚g涉及到多線程和多個服務(wù)器分別對應(yīng)的客戶端，連接到WS的沒有問題，就是SS的客戶端有問題。到今天上午為止，我已經(jīng)把GS的網(wǎng)絡(luò)處理邏輯全部靜態(tài)分析了一遍，沒有任何發(fā)現(xiàn)。臨近中午吃飯的時候，不得已只好用WS的客戶端socket去連接SS，居然出現(xiàn)同樣問題！而我的WS和SS都是放在我機(jī)器上的，這樣來看，就只有端口不同了！
果然，當(dāng)我把SS的監(jiān)聽端口修改之后，問題解決了。因?yàn)槲沂鞘褂?088端口監(jiān)聽GS連接的。當(dāng)我把端口換成80，同樣問題再次出現(xiàn)，而且SS無法通過80端口監(jiān)聽。
接下來提幾個問題：
1、
被卡巴斯基監(jiān)控的端口8088和服務(wù)器開啟的監(jiān)聽端口8088有什么聯(lián)系？為什么沒有沖突？卡巴僅僅只是從該端口獲取數(shù)據(jù)嗎？為什么網(wǎng)絡(luò)事件的FD_CONNECT的對應(yīng)iErrorCode為0（表明連接成功）？
2、
80是常規(guī)http端口，它與8080、8088這些http端口的區(qū)別在哪兒？這些端口綁定成功與否的原則是什么？
?
PS：文中關(guān)于IOCP和WSAEventSelect模型更為詳細(xì)的實(shí)現(xiàn)，可以參考
Network Programming for Microsoft Windows 2nd
的第五章：Winsock I/O Methods。
最后寫完了，發(fā)覺自己寫的很垃圾，完全就是記流水帳。轉(zhuǎn)念一想，為什么呢？自己基礎(chǔ)不扎實(shí)嘛，第一次接觸IOCP和網(wǎng)絡(luò)模型，也就這樣了。
今天太晚了，要睡了，上面的問題明天再考慮吧
J
。