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