其他

    今天下午參加了公司兄弟項目組的一個技術分享會，主題是關於MMORPG遊戲中的技能系統設計的，有幾點體會和思考，先記錄下來了！    （1）技能施法時，client只有一個上行的請求施法包，後續施法的過程全由server來驅動下發施法各階段的結果資訊，如吟唱、效果傷害、命中資訊等等；    （2）彈道類技能是由server計算飛行時間，並不考慮飛行後的軌跡，若此時目標有移動，則client會做目標跟隨的處理；   

33 #check arguments34 35 #check ip36 pattern_ip="^(([0-9]|[1-9][0-9]|1[0-9]{2}|2([0-4][0-9]|5[0-5]))\.){3}([0-9]|[1-9][0-9]|1[0-9]{2}|2([0-4][0-9]|5[0-5]))$"37 #pattern_ip="^((1?[0-9]?[0-9]|2([0-4][0-9]|5[0-5]))\.){3}(1?[0-9]?[0-9]|2([0-4][0-9]|5[0-5

目前主要的overlay技術有VXLAN、NVGRE、 STT和SPB

    這幾天，持續閱讀項目代碼，有幾點感受；1）一個軟體項目，參與開發的人越多，整個項目的代碼越有淩亂不堪的危險，需要儘可能地在項目的各個階段進行不斷的整理，也就是我們常說的重構，這是一個特別重要的事情，項目參與的人數越多，開發人員的經驗越是參差不齊，越要這樣做；2）在保證正確完成需求的基礎上，盡量把代碼寫得更美一些，諸如介面的有效提煉、對象的有效抽象、資料結構的有效選取、代碼的有效組織等等；3）對全域需求（代碼）的瞭解，有助於完善局部需求的設計與實現；

我對UML的理解：軟體工程的東西。（有點模糊，不是很懂。） 建模：個人理解——對現實的一種抽象，對現實的簡化，模型比現實更好理解。即是抽象。 UML核心元素：版型(stereotype)：版型也稱類型、構造型，它是對一個UML元素基礎定義的擴充，在同一個元素基礎定義的基礎上賦予特別的含義，使得這個元素適用於特定的場合。版型只是UML對的一種擴充手段，本身並不涉及太多的思想和方法，而是在建模的不同階段，為了區分視圖之間的而不同觀點，會採用不同的圖示來表示。（不懂，能用C++中的typename理解

關係:在UML中，關係是重要的語義。 ——關聯關係：用一條直線表示，A—B，描述不同類的對象之間的結構關係。關聯關係表示一個對象瞭解其他對象，即關聯關係描述了某個對象在一段時間內一直“知道”另一個對象的存在。例如：A對象儲存了B對象的ID，因此，A對象“知道”B對象存在。在Rose中，為了區分相互“知道”和單向“知道”的關係，定義了關聯關係的另一個變體，即單向關聯關係，如A→B，說明A“知道”B，而B“不知道”A。在用例模型中，單向關聯關係用於串連參與者和用例，箭頭由參與者之相用例，表示參與者“

如果說UML中的元素是基本詞彙，那麼視圖就是文法。整理一下UML中的視圖：靜態視圖：       顧名思義，靜態視圖就是表達靜態事物的視圖。只描述事物的靜態結構，描述其動態行為。主要有例圖、類圖和包圖。       使用案例圖： 使用案例圖（Use Case Diagram）是由軟體需求分析到最終實現的第一步，它描述人們希望如何使用一個系統。呈現了一些參與者和一些用例，以及它們之間的關係，主要用於對系統、子系統或類的功能行為進行建模。       使用案例圖由參與者（Actor）、用例（Use

     約瑟夫環問題主要分兩種，    第一種問題的描述是:N個人按順時針圍成一個圈，從1到N，然後報數，報到M的人就出去，然後剩餘的人仍然圍成一個圈，從出局的人下一個人開始重新報數，到M的人出局，如此迴圈。  

按我理解，遞迴就是不停地調用自身，到一定的臨界條件後得出結果。按照百度的說法，遞迴一般用於解決三類問題：　　(1)資料的定義是按遞迴定義的。（Fibonacci函數）　　(2)問題解法按遞迴演算法實現。（回溯）　　(3)資料的結構形式是按遞迴定義的。（樹的遍曆，圖的搜尋）遞迴的缺點：　　遞迴演算法解題相對常用的演算法如普通迴圈等，運行效率較低。因此，應該盡量避免使用遞迴，除非沒有更好的演算法或者某種特定情況，遞迴更為適合的時候。在遞迴調用的過程當中系統為每一層的返回點、局部量等開闢了棧來儲存。遞

安裝核心源碼apt-cache search kernel-sourceuname -r核心源檔案:apt-get install linux-tree-xxxxapt-get install linux-source-xxxx核心標頭檔:apt-get install linux-headers-xxxx核心編譯器:apt-get install linux-kbuild-xxxx核心鏡像做成deb的工具apt-get install

這應該是最基本的排序演算法了。具體操作如：可以看到，該演算法的特點就是像冒泡那樣，不斷把要排序的數往上升。具體程式如下：/*用二重迴圈實現，外迴圈變數設為i，內迴圈變數設為j。外迴圈重複9次，內迴圈依次重複9，8，...，1次。每次進行比較的兩個元素都是與內迴圈j有關的，它們可以分別用a[j]和a[j+1]標識，i的值依次為1,2,...,9，對於每一個i,

今天說說隊列。認識隊列這東西很久了，但一直都沒有用到。就知道是基本的資料結構。在百度和google和一段時間思考後，我選用了迴圈隊列。從百度可以得知：將向量空間想象為一個首尾相接的圓環，並稱這種向量為迴圈向量。儲存在其中的隊列稱為迴圈隊列（Circular

以前用過qt4+mplayer來用過一個播放器。感覺只是加個外殼，沒什麼意思。我同學還跟我說，mplayer不是那麼容易做的。直到現在，我還記住這句話。那時，我們一起學linux，感覺能用qt做個二次開發已經不錯。直到現在，我真正接觸ffmpeg，sdl，OSS，OpenGL。我才感覺到，原來開發一款播放器是這麼有趣。在這裡，我想整理一下思路，因為確實遇到了不少問題。播放器的一般流程（轉自網上資料）1. 輸入 : 從檔案或網路等讀取原資料，如 x.avi, x.mov, rtsp://xxx,

      遊戲伺服器程式內部都會統一設計所謂的tick機制，這個機制一般來說有兩個用途，一是許多業務模組都會有定時處理的需求，如：技能Buff計時、時間道具檢查、定時給玩家收益（打坐定時回血和藍，跳舞定時回經驗等）等等；二是遊戲伺服器內部會有一些日常主動驅動的事件，如：怪物移動、玩家移動等，這些需求都需要用到這個tick處理，誇張一點說，遊戲伺服器商務邏輯的處理絕大部分都會有涉及到tick處理的需求。     

      今天看到做的項目（具體來說是伺服器程式）被測試組同事做完壓力測試後的郵件，有一些感觸。      對於一個伺服器程式來說，效能指標無非有CPU負載、記憶體消耗、I/O回寫壓力、網路包的流量等，目前測試組的測試都是在公司內網來做的，所以，網路包的流量不是瓶頸，但從測試的結果來說，這塊恰好是我們的短板。我在想，有幾個地方可能是我們可以最佳化的地方：   

c裡面的指標很重要，但學了c這麼久了，都不知道指向函數的指標數組有什麼用，其實和用函數指標差不多。我們可以建立一個有趣的結構式指向函數的指標數組。為了選擇一個函數，只需要使用數組的下標，然後間接引用這個指標。這種方式支援表格式驅動碼(table-driven code)的概念；可以根據狀態變數（或狀態變數的組合值）去選擇被執行函數，而不用條件陳述式或case語句。這種設計方式對於要從表中添加或刪除函數（或者想動態建立或改變表）十分有用。#include<stdio.h>void

這是我遇到的第一個真正的演算法，資料結構應用問題。這也是老大問了我這問題很多天后，我才恍然，原來這叫約瑟夫環問題。這是我尋找鏈表時，發現的。長話短說，說說這上午的總結。約瑟夫環問題主要分兩種，    第一種問題的描述是:N個人按順時針圍成一個圈，從1到N，然後報數，報到M的人就出去，然後剩餘的人仍然圍成一個圈，從出局的人下一個人開始重新報數，到M的人出局，如此迴圈。   

==Building Debian Images for QEMU==Install qemu and debootstrap: apt-get install qemu debootstrapCreate image: qemu-img create disk.img 512MAssociate image file with a loopback device: losetup.orig -f # take note of the

      實際運營時，遊戲伺服器可能在任何時候core掉，一般而言，伺服器中的重要資料都會儲存在共用記憶體中，以便伺服器處理序core掉自動重啟時，能儘可能恢複到core掉前的運行狀態。最大限度地減小玩家的不適體驗，理想情況下，當然是不讓玩家感覺到伺服器core了。      這裡想到的一個問題是：當server

ftrace主要是用來協助開發人員瞭解Linux核心的運行軌跡，以便進行故障調試或效能分析。它是在2.6.27核心中開始出現的，自此以後，不斷有新的tracer加入，到2.6.30為止最少已經有10種tracer。具體的tracer可以參閱/Documentation/trace/ftrace.txt。本文主要說明ftrace的使用方法：要使用ftrace必須在核心中首先添加對其的支援，也就是要重新編譯一個新的核心。Kernel hacking     Tracers