近來，對wow現有的模擬器的看法又有了新的變化。
ascent接觸了很久，執行機制也算比較了解，但是始終有個遺憾。
先簡述一下結構：iocp負責網路io，多執行緒處理，加入封包佇列。
主迴圈（單執行緒）更新每個會話，讀取封包，並交給對應的handle函式（還是主迴圈的執行緒）。
週期完畢，檢查如果花的時間短，等待再進入下個更新週期，超時了則馬上進入下個週期。
問題就在此產生：
一、ascent的執行緒池形同虛設，現有的執行緒池其實只是個manager或container，並沒有發揮執行緒池的作用。執行緒池存在的理由就是避免為新的請求產生和銷毀執行緒造成開銷，迴圈利用執行緒。
二、分析一下伺服器的工作型別。
按照《c++網路程式設計，卷一》，第五章，第一節中三種伺服器型別的定義，迴圈、併發及反應式伺服器。
ascent是不折不扣的反應式伺服器，同時也屬於迴圈式，該型別結構最適合：1.短期服務；2.不經常執行的服務
「由於這樣一種迴圈式結構，每乙個請求處理都會在乙個相對粗糙的層次上被序列化-例如，在應用程式和os同步事件多路分離程式之間的介面上。但是，這種粗糙層次上的併發性不會充分利用主機平台上的某些處理資源和os特性」—— 《c++網路程式設計，卷一》，5.1節如此說來，ascent效能並不佳，提公升的空間還很大。
但事情沒這麼簡單，效能無法單純用架構衡量。考慮乙個問題，如果多執行緒應答封包會發生什麼。
我曾嘗試將處理多執行緒化，雙開wow進去跑，差不多10分鐘左右，伺服器就會發生死鎖，屢試不爽。
原因很簡單，作為網遊伺服器，需要同步的資料太多了，我們曾被unordered_***系列的boost庫容器玩瘋了。
完美的同步都會發生資料結構損壞，出現壞鍊錶，簡直匪夷所思。
推想下去，如果真的多執行緒並行處理，那麼同步量會大到令人髮指，幾乎所有資料都需要同步，多到令我覺得乾脆按類序列化得了。
真羨慕windows的可重入api的設計，如果win的api不是可重入的。。。
技術上講，認為，尋求一種穩定的並行構架是模擬器的目標。
魔獸世界WOW伺服器端的模擬器 2010
記不清從什麼時候開始，國內出現了很多所謂的魔獸世界私服 而且在 上還有什麼魔獸世界單機版在 其實這些東西都是利用國外的一些開源軟體如mangos和arcemu來實現的。一 mangos 開發小組一再強調，這是個研究和教育性質的 對怎樣開發大型網遊的伺服器端有好處的專案，是乙個技術細節毫無保留向公眾開...
linux下對gens遊戲模擬器的編譯
gens版本 gens gs v2.15.5 gs m5 gens gs linux版本 version 2.6.27.9 159.fc10.i686 gcc版本 4.3.2 編譯過程 因為源 中已經存在configure檔案，所以不需要通過工程管理工具autoconf自動生成 首先在源 目錄下執行...
android中對服務端的長連線 socket
來自於 我們有時候有這種需求，即我們的android客戶端要始終保持與服務端的連線，當服務端有任務或訊息傳送到android客戶端的時候就傳送，沒有任務或訊息的時候不傳送但要保持這個連線，一旦有任務則開發傳送，而我們的android客戶端則要保持乙個時刻接收任務或訊息的狀態。這個時候我們通過sock...