1、什麼是強聯網和弱聯網以及區別
一、強聯網
1、什麼是強聯網？
我們通常說的強聯網其實就是用Socket（套接字）連接，也叫強連接，長連接。
2、協議分配
以Tcp協議和Udp協議為主
3、Socket構成
Socket(套接字)=網路地址(IP)+埠號(Port)
4、使用原理
基本的socket通信伺服器端主要需要確定埠，同時綁定埠進行監聽，一旦有從客戶端法過來的連接請求就建立連接並收發消息。
5、特點
Socket通信具有實時性、長連接的特點。
6、應用
根據Socket通信的特點，我們很容易想到那些實時對戰，多人在線的游戲都是用強聯網。
二、弱聯網
1、什麼是弱聯網？
弱聯網是HTTP協議（超文本傳輸協議 ），是互聯網上應用最為廣泛的一種網路協議。
2、協議分配
HTTP協議和HTTPS協議等
3、通信方式
Get和Post
4、使用原理
基於網址連接，我們在瀏覽器的地址欄里輸入的網站地址叫做URL (Uniform Resource Locator，統一資源定位符)。每個網頁也都有一個Internet地址。當你在瀏覽器的地址框中輸入一個URL或是單擊一個超級鏈接時，URL就確定了要瀏覽的地址。瀏覽器通過超文本傳輸協議(HTTP)，將Web伺服器上站點的網頁代碼提取出來，並翻譯成漂亮的網頁，或者說獲取到了你想要的資源。
5、特點
每次連接只處理一個請求，當伺服器處理完客戶端的請求即端開連接，節省傳輸時間。
6、應用
實現登錄、注冊、選服功能，游戲角色信息，商城等窗口信息的獲取，伺服器與資料庫通信等。
2、游戲中框架限制器是什麼
伺服器是用來處理高並發的請求，同時能夠滿足擴展的業務邏輯的需求，最重要的是滿足三點：並發性，穩定性，擴展性。
經歷過兩款上線游戲產品，見識到了游戲行業的雜亂無章，雖然和傳統軟體行業相比，少了那麼些規范，但是對個人能力要求還真不比傳統軟體行業低。
今天開始，陸續利用業余時間將自己設計的一個伺服器的框架貼出來，也會包好一些基本的代碼，也會用到一些開源庫。從最基礎的講起，首先看看一個實時網路游戲伺服器的框架:
目前市面上的游戲，總的來說分為兩類：
1.弱聯網類游戲，像手機上的卡牌類游戲(MT,Dota傳奇等)，大部分邏輯在客戶端處理，不需要實時聯網，這類游戲只有一個玩家，而且只有PVE模式，就是打游戲中的機器人(AI)，不存在玩家與玩家的實時交互。例如一場副本打鬥，只有在開始和結束，才會連接伺服器，請求獲取或者存儲數據，打鬥過程由客戶端計算完成，最後將戰斗結果提交伺服器就行了。
2.強聯網類游戲，典型的就是MMORPG或者MMARPG的類型的游戲，一般常見於端游或者頁游，也包含手游。在一個地圖中，同時有很多玩家，任何一個玩家的狀態或者屬性發生變化，伺服器就需要實時更新游戲中角色的狀態，並且通知到周圍的玩家。例如在副本中，一個玩家釋放技能，攻擊范圍，傷害計算這些邏輯都是伺服器來完成的，而客戶端只需要負責特效的顯示，這個過程中需要實時的數據交互。
顯然，第2種，MMORPG類游戲需要伺服器做更多的事情，對伺服器的運算要求更高，實時性要求更高，自然實現起來更復雜。
一個大型的網落游戲伺服器應該包含幾個模塊：網路通訊，業務邏輯，數據存儲，守護監控（不是必須），其中業務邏輯可能根據具體需要，又劃分為好幾個子模塊。
這里說的模塊可以指一個進程，或者一個線程方式存在，本質上就是一些類的封裝。
對於伺服器的並發性，要麼採用單進程多線程，要麼採用多進程單線程的方式，說說兩種方式的優缺點：
一、單進程多線程的伺服器設計模式，只有一個進程，但一個進程包好多個線程：
網路通訊層，業務邏輯，數據存儲，分別在獨立的線程中，無守護進程。
優點：
1.數據共享和交換方便，使用全局變數或者單例就可以，數據存儲方便。
2.單進程，伺服器框架結構相對簡單，編碼容易。
缺點：
1.所有功能只能在單個物理伺服器上，不能做成分布式。
2.不方便監控各個線程狀態，容易死鎖
3.一個線程出錯，例如內存非法訪問，棧空間被破壞，那麼伺服器進程就退出，所有玩家掉線，影響大。
二、多進程單線程的伺服器設計模式，多個進程，每個進程只有一個線程：
網路通訊，業務邏輯，數據存儲，守護進程，分別在不同的進程。
優點：
1.各個進程可以分布在不同的物理伺服器上，可以做成分布式的伺服器框架，例如可以將數據存儲單獨放到一個物理伺服器上，供幾個區的伺服器使用。將網路通訊進程獨立出來，甚至可以做成導向伺服器，實現跨服戰。
2.可以通過守護進程監控其它進程狀態，例如有進程死掉，馬上重啟該進程，或者某個進程cpu使用率接近100%（基本可以判斷是某個邏輯死循環了）, 強制kill掉該進程，然後重啟。
3.單個伺服器進程異常退出，只要不是網路通訊進程（一般這個都會比較穩定，沒什麼邏輯），那麼就可以及時被守護進程重啟，不會造成玩家掉線，只會造成在1-2秒內，某個邏輯功能無法使用，甚至玩家都感覺不到。
4.伺服器通過共享內存進行數據交換，那麼如果其中一個伺服器死掉，數據還在，可以保護用戶數據（當然多線程也可以使用共享內存）。
5.並發性相對多線程要高點。
缺點：
1.不方便使用互斥鎖，因為進程切換的時間片遠遠於線程切換，對於一個高並發伺服器是無法允許這么高時間片的切換代價的。因此必須設計好伺服器的框架，盡量避開使用鎖機制，但要保證數據不出錯。
2.多進程編程，在各個進程間會有很多通訊，跨伺服器進程的非同步消息較多，會讓伺服器的編碼難度加大。
3、糖果傳奇進度被封所該怎麼解開
你試試換個號登陸，然後再登一下這個號，切換賬號應該有效果
4、java游戲伺服器開發有前途嗎
最近剛跳槽，到新公司已經幹了有兩周時間了，這兩周時間是過得比較充實的，因為這家新公司是個小公司，以前以單機開發為主，伺服器方面我一個人，做兩個游戲的伺服器開發工作，當然，一個很簡單，另一個就相對復雜點，簡單的那個是個弱聯網游戲，伺服器只需要做好數據存檔和登錄支付驗證就好了，而另一個，則是相對復雜的slg游戲，我感覺這是又一款cok，而公司目前並不打算再招伺服器了，所以估計這個項目我會一個人干到明年吧，等第一款上線賺錢了，可能會再招伺服器。老實說，面試的時候，我就覺得這份工作對我而言是一個挑戰，而當我清楚的了解了公司狀況之後，我依然決定接受這個挑戰。
說說我之前的經歷吧，大四的時候，學校安排來北京培訓java（培訓沒什麼丟臉的，出來找工作我也用的真學歷真背景，不像某峰互聯），之後我去了培訓機構推薦的公司實習，那個時候，工資2k，然而工作也幹得很開心，跟著前輩學到了不少東西，當時是做微信公眾號開發的，我跟著前輩做微信後台開發，當時使用SpringMVC+MyBatis框架，剛接觸的時候，我自己學了挺久才弄明白，後來弄明白之後想想，其實挺簡單，對於邏輯開發的程序員來說，你只需要弄懂工作流程就好了，頁面怎麼跳轉，跳轉怎麼傳值，數據怎麼處理，這些足夠了，當然我是個不滿足的人，我會去弄明白，為什麼用這個框架、為什麼不用別的、用這個有什麼好處、如果讓我自己來做這個後台、我會怎麼搭建？帶著這些問題，我會試著自己搭建一下後台框架（雖然前期大部分是復制粘貼）。除了框架部分，微信高級介面也是我研究的重點，我會去官方文檔看看微信是怎麼接入的，然後研究研究前輩的代碼是怎麼寫的，所謂的干一行愛一行大概就是這樣吧，當時我覺得，微信開發，是很有前途的，而我們公司用的框架，也是最先進的（後來看來，確實這個框架組合是當前最流行的框架，而當時，微信公眾號也確實是當時互聯網行業的一個風口，微信後來把h5帶起來了，導致現在一個好的h5前端都是供不應求的，薪資很高）。
說了這么多，為什麼後來又轉行做游戲了呢？其實是這樣的，當時在第一家公司，我的上級打算跳槽走了，帶走整個下面的技術，而不帶實習生，有那麼一兩個月，實習生就一直閑著沒事做，對於我來說，這樣過著就太無聊了，我喜歡挑戰，於是我投簡歷，重新找了份實習工作，在一個游戲公司做java伺服器開發，公司挺大的，幾年前憑借一款slg頁游稱霸游戲行業（什麼游戲我就不說了，說了就知道什麼公司了），後來游戲行業往手游發展，這款slg也出了手游版，這一款游戲，幾乎支撐了整個公司，再加上後來出的幾款手游，公司發展挺好的，我所實習的部門做的是一款mmorpg手游，從實習做到了轉正，做了近一年了，然而這款rpg手游的數據卻不是太好，第一次封測次日留存23，第二次26（現在這家公司的游戲能達到80多次日留存），七日就更不用說了，而我也能感覺到，作為一款mmo游戲，玩家之間的交互實在太少，從頭玩下來，我覺得這是一款單機，失去了mmo的本質，在項目組准備進行第三次封測的時候，我選擇了離開，原因很多，不僅僅因為游戲數據不好，也有一些個人原因吧，不過說實話，是這家公司帶我走進了游戲行業，我很感謝，我覺得游戲行業是一個非常有前景的行業，甚至比之前我認為最好的微信開發還要好，游戲行業非常暴利，在這家公司工作就能感受到，策劃文檔中，充滿了挖坑預留的計費點，這一塊可以正常玩兒，但你如果充錢，你就比別人牛逼。網路游戲，最重要的，就是控制好平民玩家跟普通玩家的佔比以及游戲平衡（當意識到公司的游戲如此處心積慮想要坑錢的時候，我突然明白為什麼公司的游戲大多被騰訊代理了，為什麼騰訊控股，原來如此，沒錢玩兒你**，哈哈）。由此也可以看出，游戲的商業化，已經把游戲公司帶入了一個固定的模式——無條件坑錢，我覺得已經失去了游戲的本質，我看過一本書，叫《游戲人生》（當時在cocos2014年開發者大會上買的。覺得挺值的），書已經送人了，但內容我看了一大半，從游戲的產生，到玩家的心理，到為什麼需要游戲，這本書都詮釋的熱別好（我覺得游戲策劃都應該看看這本書，做良心游戲，拒絕一味坑錢）。啊，突然發現這一段說的有點偏了，說到底，我也只是做游戲伺服器開發的，我也改變不了游戲行業，我只要做好我做的。其實大的游戲公司，就應該走這種商業化路線，憑借幾款長生命周期的游戲，支撐公司流水。
從轉行做游戲之後，我倒是覺得，游戲開發比web開發有趣多了，當然技術上也比web難多了，之前發過一篇討論，web開發何和游戲開發的區別，http://gad.qq.com/content/wendetail/7082370，我把我的答案再粘貼一遍（實際上是別人要求我上他的號去回答的，於是我就自己回答了我自己的問題）：
1.從第三方支持來說，web後台有很多成熟的第三方框架，開發者不需要關心底層控制器跳轉的實現，只需要一個或幾個配置文件，就能完成核心控制器的部分，而開發者只需要關注web自身的業務邏輯，將邏輯與框架融合即可，使用框架一方面簡化控制層代碼，一方面很好的實現了業務邏輯的分層。而游戲後台開發中，因為各種游戲的需求差異性很大，從網路層，到業務邏輯層，各方面都必須根據自己游戲需求搭建適合自己的框架，因此很難有一些通用的東西能提煉出來一款成熟的框架，游戲後台開發基本上需要自己搭建適合自己的框架。
2.從業務邏輯層面來說，web後台基本上邏輯都是大同小異的，或許這一套系統，稍微改改，另一套系統就能用，而游戲就不同了，每個游戲都有自己的特色，根據策劃的不同需求而實現不同的邏輯，不過也會有一些通用的模塊，但整體上差異性還是很大的。
3.從數據持久化來說，web的數據基本上是很規整的，表與表之間關系很明確，並且以後也不會有太大的變化，而游戲中的數據多種多樣，隨著開服之後，數據的變化也是多種多樣，甚至傳統的關系型資料庫根本無法滿足游戲數據持久化的需求，游戲中有很多狀態和數據是需要伺服器來保存的，我個人認為，在游戲開發中，nosql比關系型資料庫更實用。
4.從通信層來說，web中的用戶都是一個個獨立的個體，而游戲中是多人在線的一個游戲世界，在這個游戲世界中，玩家與玩家之間需要進行交互，這就需要伺服器實時的向所有在線玩家進行消息廣播，這一點很損耗伺服器性能的，在這方面，游戲後台要比web做更多的處理，游戲伺服器是一個IO密集的伺服器類型。
以上便是我當時的答案，或許我的見解尚淺，畢竟我做游戲不到一年，不過對於後台開發這塊，我還是有一點話語權的，從實習游戲開發開始，我便經歷了一個轉換的過程，幾乎又是一個從零開始的學習過程，從mina框架到protobuffer，這些東西，我相信web開發很少接觸（mina作為網路通信框架，web中幾乎只有http通信，protobuffer作為通信協議，web最多用json，其實二者形式上差別不大，但數據大小千差萬別）。而游戲的邏輯，也是比web復雜得多，不得不說，web後台成熟的第三方框架是做的真的很好。
經歷了上家公司的洗禮，我想我對游戲後台開發有了足夠的了解，於是我找到了我現在這家公司，這家公司目前只有我一個伺服器後台，做兩款游戲，一款是塔防類，准備由單機改成弱聯網，伺服器存檔，並做登錄支付驗證，另一款，是比較龐大的slg手游，是准備帶領公司走上巔峰的項目，說一款slg帶領一個公司走上巔峰一點兒不為過，我上家公司就是這樣的，憑借一款《xxxx》（哈哈，名字不透露），走上人生巔峰。我之所以接受這份工作，是因為我接受挑戰，從底層寫起，從架構寫起，這是作為一年工作經驗的我想都不敢想的，不過這是一個挑戰自我，證明自我的機會，我願意接受這個挑戰，人生總會有很多爬坑的時候，但爬過了坑，就真的是人生巔峰了。我接受這個工作的另一個原因，就是公司發展確實不錯，以前做的單機，都是很火的（雖然我認為我自己一個人也能做，我也是學過cocos的），而現在公司也准確的把握了游戲行業的風口——slg，coc和cok的成功案例就能證明一切，mmorpg也不一定能做起來了，moba倒是有可能，但你要跟lol做不到80%的相似，我估計沒人願意在手機玩兒moba，slg或許是性價比最高的了。這么有挑戰的工作，還要從架構寫起，這樣的挑戰，我喜歡！
說說互聯網業的書吧，我認為這個行業的書，分為兩種，理論型的和技術型的，所謂理論型，就是長篇大論互聯網發展，行業模式等，而技術型，就是類似技術的工具書，是從技能入手的書，這兩種書，我家裡都有，但我發現買了之後，我很少有時間看，下班沒多少時間，北京上班，大多數時間都浪費在地鐵上了，上班時間，看看理論型的吧，覺得啰嗦，浪費時間（後來我發現，做這行，除了會技術，你還是需要去看看牛人眼中的互聯網的，你需要透過前輩的眼光看世界，不要做IT民工，要做互聯網從業者），看看技術型的吧，讓別人看見了感覺你太low，所以我大多數時間還是能在網上down到pdf就在電腦看，down不到百度谷歌我要研究的技術，畢竟從事這行，還是用電腦學技術好點，主要是電腦看久了眼睛會疲憊，偶爾看看紙質的書也不錯的。而以前面試的時候，面試官經常問，除了大學課本，你還看什麼書啊？（如果是你們，恰巧又沒看什麼書，你們怎麼說？），我一般會說，我會自學其他技術，如cocos2dx，然後買一些技術指南之類的書看。我覺得這已經算最大誇張化了，因為大學我真的很少看書，我記憶中就看過一本C++技術類的，一本C#的，一本Android，還有其他幾本是什麼都不大記得了，大學畢竟十幾層的圖書館，除了英語四六級的時候進去復習，其他時間感覺都浪費了這十幾層的圖書館。
說說成長過程中遇到的問題吧，如果遇到我解決不了的，以前是先自己百度谷歌，看看有沒有辦法解決，不行就問老大，而現在，先百度谷歌，看有沒有辦法解決，沒辦法在百度谷歌，實在不行還要看框架源碼如何實現，上國外論壇看外國友人如何解決，問題總能解決的，總會有辦法的。當我開始學習寫架構的時候，我會開始關心游戲的網路層使用什麼框架，mina還是netty，數據怎麼存儲mysql還是mongo，是否需要緩存redis存什麼，memcached存什麼，緩存什麼數據，數據傳輸用什麼協議，json還是protobuffer，怎麼寫效率高，最高支持多少並發等等，我想這些都是我現在需要考慮的問題，當然這些都需要根據游戲具體的需求來決定的，最終伺服器能否高效穩定的運行，都是取決於我的架構是否高效穩定，所以這個過程我要不斷學習，不斷吸取別人的經驗。剛到新公司的時候，我才體會到，自己寫代碼其實也是一種挑戰，整個後端我自己一個人實現，代碼是否規范，數據如何存儲，都是我說了算，我想我的代碼不僅要高效，還要讓別人看得懂，後來的人能接著我的代碼繼續寫下去。
最後說說Java的題外話，語言之爭，從未停過，為什麼有人擁護Java，有人擁護PHP，有人喜歡C#，有人喜歡C++，各個語言各有各的優勢，業余時間，我也了解了不少其他語言，go，node.js我都有了解，我覺得go的語言層面支持協程並發以及node.js的非同步，都是很適合游戲伺服器的，我特別看好node.js，非同步io真的是對游戲伺服器很好的特性，並且加入對原聲js支持的mongo模塊也是很方便的（上面我有說到，我相信nosql是很適合存儲游戲數據的）。說到游戲行業，我認為h5游戲的發展也是越來越快了，上次白鷺的h5開發者生態大會我去了，白鷺的一整套工作流程，以及web vr，真的很令人興奮（第一輪抽獎我還抽了一個暴風魔鏡，哈哈！），另外，大會的模特挺漂亮，哈哈！2015年，互聯網行業也略呈下降趨勢了，不少創業公司面臨倒閉，泡沫經濟破滅，因為很多老闆抓不住當前經濟形勢，以為不管是啥，有個app就是創業了，其實全然不知一款app後面有多少運營模式、盈利模式，就像一句諷刺的話，「我有個絕壁好的idea，可以顛覆bat，什麼都不缺，就缺個程序員了，等等，千萬別告訴馬雲！」，哈哈，聽到這句話，當時我就笑了，估計好多倒閉的創業公司老闆都這么想的吧，他們並不能抓住用戶真正的需求，只有抓住用戶真正的需求，才會抓住用戶的心，真正活下來的，才是用戶真正需要的，然而，相對來說，游戲行業更是復雜多變，或許今天玩家喜歡這種游戲，明天玩家就喜歡另一種游戲了，就像我們永遠也想不到，flappy bird、圍住神經病貓這類的游戲竟然能活起來，愚公移山竟然也能讓h5游戲變為付費的可能。就像一句話，「只要站在風口上，豬也能飛起來！」，只要抓住了玩家此時此刻真正想要的，產品就一定能做起來。
5、做一個RPG弱聯網游戲伺服器應該存儲哪些東西？
一般就是玩家的基本數據，比如等級經驗，之類的
6、cocos2dx 弱聯網 怎麼做
下面是官方給出的教程
介紹
HttpClient是HTTP客戶端的介面。HttpClient封裝了各種對象，處理cookies，身份認證，連接管理等。
概念
HttpClient的使用一般包含下面6個步驟：
創建 HttpRequest 的實例；
設置某種連接方法的類型（GET、POST等），這里通過setUrl傳入待連接的地址；
設置響應回調函數，讀取response；
添加請求到HttpClient任務隊列；
釋放連接。無論執行方法是否成功，都必須釋放連接；
對得到後的內容進行處理。
如何使用
HttpRequest 實例
我們將使用HttpRequest無參數的構造函數，它為大多數情況提供了一個很好的默認設置，所以我們使用它。
cocos2d::extension::HttpRequest* request = new cocos2d::extension::HttpRequest();
設置連接方法的類型和待連接的地址
由HTTP規范定義的各種方法對應各種不同的HttpRequest類。
我們將使用Get方法，這是一個簡單的方法，它只是簡單地取得一個URL，獲取URL指向的文檔。
request->setRequestType(HttpRequest::Type::GET);
request->setUrl("");
設置回調
無論伺服器返回怎樣的狀態，響應主體response body總是可讀的，這至關重要。
request->setResponseCallback(this,httpresponse_selector(HelloWorld::onHttpComplete));
在onHttpComplete里讀取響應數據：
std::vector *buffer = response->getResponseData();//Get the request data pointer back
添加請求到HttpClient任務隊列
cocos2d::network::HttpClient::getInstance()->send(request);
釋放連接
這是一個可以讓整個流程變得完整的關鍵步驟, 我們必須告訴HttpClient，我們已經完成了連接，並且它現在可以重用。如果不這樣做的話，HttpClient將無限期地等待一個連接釋放，以便它可以重用。
要釋放連接，使用:
request->release();
處理響應
現在，我們已經完成了與HttpClient的交互，可以集中精力做我們需要處理的數據。在這個例子中，我們僅僅將它在控制台上輸出。
// mp data
std::vector *buffer = response->getResponseData();
printf("Http Test, mp data: ");
for (unsigned int i = 0; i <</span> buffer->size(); i++)
{
printf("%c", (*buffer)[i]);
}
printf("\n");
如果你需要把response作為一個流來讀取它裡面的信息，上面的步驟將會同如何解析這個連接結合，當你處理完所有的數據後，關閉輸入流，並釋放該連接。
GET請求示例
下面是一個通過HttpClient的HTTP GET請求的例子。
HttpRequest* request = new HttpRequest();
request->setUrl("");
request->setRequestType(HttpRequest::Type::GET);
request->setResponseCallback(this, httpresponse_selector(HelloWorld::onHttpRequestCompleted));
request->setTag("GET test111");
cocos2d::network::HttpClient::getInstance()->send(request);
request->release();
POST請求示例
下面將發送一個POST請求到URL逗地。
HttpRequest* request = new HttpRequest();
request->setUrl("");
request->setRequestType(HttpRequest::Type::POST);
request->setResponseCallback(this, httpresponse_selector(HelloWorld::onHttpRequestCompleted));
// write the post data
const char* postData = "visitor=cocos2d&TestSuite=Extensions Test/NetworkTest";
request->setRequestData(postData, strlen(postData));
request->setTag("POST test1");
cocos2d::network::HttpClient::getInstance()->send(request);
request->release();
處理網路回調函數
void HelloWorld::onHttpRequestCompleted(HttpClient *sender, HttpResponse *response)
{
if (!response)
{
return;
}
// You can get original request type from: response->request->reqType
if (0 != strlen(response->getHttpRequest()->getTag()))
{
log("%s completed", response->getHttpRequest()->getTag());
}
int statusCode = response->getResponseCode();
char statusString[64] = {};
sprintf(statusString, "HTTP Status Code: %d, tag = %s", statusCode, response->getHttpRequest()->getTag());
_labelStatusCode->setString(statusString);
log("response code: %d", statusCode);
if (!response->isSucceed())
{
log("response failed");
log("error buffer: %s", response->getErrorBuffer());
return;
}
// mp data
std::vector *buffer = response->getResponseData();
printf("Http Test, mp data: ");
for (unsigned int i = 0; i <</span> buffer->size(); i++)
{
printf("%c", (*buffer)[i]);
}
printf("\n");
}
Android
需要注意的是，如果你是Android環境，不要忘了在您的應用程序的Manifest
中增加相應的許可權：
android:name=地android.permission.INTERNET地 />
詳細代碼可參照..\samples\Cpp\TestCpp\Classes\ExtensionsTest\NetworkTest\HttpClientTest.cpp
7、那些游戲服務端是java寫得？
看游戲是什麼聯網類型了。
如果是弱聯網，那麼就是設置介面請求那些的。這些和內做java web基本也沒什麼容區別，而且還少前端的頁面展示。只需要將數據封裝成json或者其他格式接收解析保存，然後在給客戶端返回結果就好了。
如果是實時聯網，這塊我沒怎麼做過。不過需要熟練使用socket肯定是必須的了。
8、弱聯網游戲伺服器端問題
自然是可以的，只不過隨著游戲版本的迭代和用戶數據的增多，伺服器負載和模塊間耦合會增加，維護難度提升
9、PHP 弱聯網游戲怎樣實現金幣的同步
客戶端只存儲發送特徵代碼（例如參戰人物的ID、所購買物品的ID等），其餘存版儲和權計算（如根據參戰人物的屬性計算戰斗過程和結果、用戶賬戶是否有足夠購買所選物品等）全都由伺服器端完成。關於賬戶內的人物、等級、金幣等數據全部是存儲在伺服器端，只在登錄和有用戶交互被提交至伺服器時進行計算和同步
10、9游破解游戲的方法是什麼？
解包，然後修改游戲數值，重新封包，破解版游戲就出來了，理論上只要想破解，沒有破不了的
上述針對單機游戲
所以現在很多游戲都是弱聯網或者聯網，重要數據都在發行商伺服器，想破就得破了人家伺服器，所以很少有直接能改數值的網游