1. 架構說明 目前的協議有如下一些特點: 1) 客戶向服務器發送請求, 每個請求的長度不定. 請求的長度在第一個INT中指定. 2) 每個服務器通常會向多種客戶提供服務, 例如, TS要同時向CP, NP提供服務, CP要向NP和其他CP提供服務, 同時還是其他CP, TS, SP的客戶. 3) 每個服務器為客戶服務時, 通常是長期的, 會涉及多次請求-應答的來回. 這樣的結構, 主要是為了能夠支持大量并發客戶連接而設計的. 在具有大量并發客戶 連接時, 無論采用線程還是進程, 都無法進行有效的服務, 因此必須采用select 輪詢方式. 2. 基本數據結構說明 對于每個客戶端, 需要保存該客戶端相應的一些信息. 目前的CPnew.c, SPnew.c 和TSnew.c的核心數據結構基本相同, 都由Session, SessionCluster (TSnew.c中) 或者 ServerDesc (CPnew.c和SPnew.c)構成. 其中, Session是每個客戶端相關的數據, SessionCluster(或者是ServerDesc)是 有關每種服務的信息, 其中有一個指向該服務相關的各個Session的指針. Session 這一數據結構不是在有客戶請求時動態分配的, 而是在最開始初始化時就已經分配 好的, 當有新客戶請求到來時, 服務器搜索這一預先分配好的這些Session, 發現其中 有空閑則使用, 如果沒有空閑就報告錯誤. 對于TS和CP(SP)來說, 最大的區別是TS使用UDP協議, 而CP和SP則使用TCP協議, 二者的 不同在于: 1) 對于TCP協議的客戶端, 由于每個客戶端都使用不同的socket, 因此select之后 只需要看各個客戶端的fd_set是否置位就可以了, 而對于UDP客戶端, 找到相應的 客戶端需要進行一次查找過程. TS使用了一些措施來減輕查找所帶來的開銷. 2) TCP協議中, 發來得數據是流形式的, 因此需要進行消息分塊, 有可能兩個消息 在一次read中讀完, 也有可能一個消息需要讀很多次, 這兩種情況都需要考慮, 因此 每個Session中都有一個buf, rstart, rlen, 用來存儲讀來但還沒有處理的消息, 同樣, 寫的過程中也需要考慮寫的時候有可能沒有一次寫完, 因此也需要每個Session中 保留wbuf, wstart, wlen三項. UDP中則不同, 在協議實現中假設每個UDP數據包中 所包含的消息都是完整的, 因此沒有這幾項. SessionCluster(或者是ServerDesc)來說, 描述了一個服務, 這個服務由這樣幾個 主要的部分構成 1) sock: 描述所所使用的socket 2) cur: 當前客戶端的個數 3) max: 最多容納客戶端的個數 4) head: Session的頭, head[0]為第一個Session, head[max-1]為最后一個session 5) init: 這一服務中每個Session需要執行的初始化操作. (函數指針) 6) process: 這一服務中消息的處理函數 7) closure: 這一服務中需要的析構函數 3. 主要結構說明 process_child: 主要函數, 這一函數主要用來 設置socks和wsocks, 對于SP和CP, 只有Session的wlen>0的時候才設置wsocks; select; 對于每個ServerDesc(或者SessionCluster), 進行process_type 在SP和CP中, 為了支持PUSHLIST操作, 在每一次循環前先要進行processJob 在CP中, 還周期進行periodCheck, 用來將過期的連結清除 在TS中, 周期進行periodLog, 用來將過期的客戶連接清除 process_type: 對于每個Session, 檢查是否可讀. 如果可讀, 檢查是否有完整的消息, *(unsigned int *)(rbuf+rstart) <= rlen 調用相應的process直到沒有完整的消息為止 檢查是否可寫, 如果可寫且wlen>0, 則進行寫 4. 其他重要的模塊 1) 配置模塊 配置模塊主要由struct NamVal, read_config, free_config組成, NamVal結構中, Name是在cfg文件中的名字, ptr是指向存放的指針, type是數據的類型, 目前支持這樣 幾種類型 'd': 整數類型, ptr是一個整數指針 's': 字符串類型, ptr是一個指向指針的指針, (char **) 'b': 字符串buffer類型, ptr是一個char *, 使用這種類型時應當注意, 對于's