閘道器伺服器之結構調整
在開發wap閘道器伺服器過程中，結構由開始的固定僵化，到後來理解了iocp的實質之後的統一，經歷了一番變化，總結如下。
從邏輯上而言，wap閘道器伺服器是分兩部分的 。一部分和數量龐大的終端進行互動（前端），另一部分和iag伺服器互動，上傳終端資料和接收指令（後台）。最初我是用iocp來處理前端，後台只建立一條tcp連線，用標準三線程+重疊模型來上傳和接收資料。這樣的邏輯看上去很美，呵呵~~
但後來遇到乙個問題，由於iag伺服器之前是與終端直連的，因此下發資訊並不包含sim卡號。即wap閘道器伺服器收到的資訊無法確認是哪個終端的，採用一條tcp連線的方式走不通，這樣只有為伺服器內部為每個終端建立對應的與iag伺服器連線的socket(由於是在同一內網，用的是udp)。
由於我的思維定式，潛意識把與iag互動的udp socket作為後台的一部分來處理，如何處理這批和前端終端數量相同的socket的io成為了乙個問題。最初我幼稚的把每個udp socket做成了非同步的socket，輪循的處理它們的io請求，後來意識到完成埠佇列能夠處理任何與之關聯的socket io請求，不論這些socket是否連線的目標是否相同，是否是接收的還是發起的。於是我在後台也建立了乙個iocp來處理這些udp socket的io請求。
之後我以為到頭了，兩個iocp分別處理前端和後台，tcp和udp兩種型別的socket io，這是非常自然和明晰的結果。但在晚上總結心得的時候，突然意識到為什麼要用兩個iocp來分別處理這面向兩個方面兩種型別的socket呢？既然iocp能夠無差別處理socket的io，它只是乙個訊息佇列，接收所有關聯的socket io訊息。這樣我只需使用乙個iocp來處理所有的tcp和udp socket io，在投遞io請求時做上各自的標記即可。
於是按上述想法進行改動，在形式上是所有的socket一併被處理，但邏輯上還是分開的。為此自己還得意了一把，後來看到乙個前輩開發閘道器的文章，發現他也是這樣處理，呵呵 ，自己只是後知後覺而已~~~
閘道器伺服器
之前想著要把什麼什麼給寫一下，每次都太懶了，都是想起了才來寫一下。今天只討論遊戲伺服器的閘道器伺服器。1.2.心跳 閘道器定時傳送心跳給連線在這個閘道器上的所有客戶端，保證客戶端與閘道器的連線，如果某個客戶端掉線了，那麼閘道器就通知各個伺服器去做玩家的下線處理 3.負載均衡 多閘道器來支援平衡遊戲負...
閘道器伺服器
之前想著要把什麼什麼給寫一下，每次都太懶了，都是想起了才來寫一下。今天只討論遊戲伺服器的閘道器伺服器。1.2.心跳 閘道器定時傳送心跳給連線在這個閘道器上的所有客戶端，保證客戶端與閘道器的連線，如果某個客戶端掉線了，那麼閘道器就通知各個伺服器去做玩家的下線處理 3.負載均衡 多閘道器來支援平衡遊戲負...
調整KVM伺服器
通過對kvm伺服器做適當調整，為kvm虛擬機器的網路訪問及磁碟儲存提供條件。主要完成以下事項 1 建立隔離網絡卡virbr1 2 建立橋接網絡卡br0 3 建立乙個不小於40g的檔案系統，掛載到 data 作為虛擬機器的專用空間 kvm的虛擬網路型別 1 橋接模式 guest與host連線到同乙個交...