摘要: 存儲過程的錯誤捕捉 mysql_next_result > 0
閱讀全文
1- 遇到問題，要去思考如何解決這類問題，而不是這個問題。
2- 不要因為時間緊迫而放棄代碼的重構。
3- 如果覺得有必要改，就去改，不要怕混亂，它只是暫時的。堅持到底，就會云開見月明。
1- 輸入和輸出流，底層采用分頁數據容器。
2- 可定制的流過濾器，協議分析、數據安全、以及轉發邏輯都可以通過這個來完成。
3- 三種可定制的主循環：1- 單獨邏輯線程 2- 主線程直接循環 3- 作為TASK在主線程池內執行。
4- UDP支持。
1- 為AGENT增加了主動模式，應用服務可以主動連接AGENT，從而讓地址無法確定的APP服務可以掛接到地址固定的AGENT上提供服務。
摘要: XLIBPLUS庫和XNETWORK庫的源代碼。
閱讀全文
摘要: XSE2.0 的源代碼（包含C\C++\C#示例）
XSE全名為 X Server Engine，是在IOCP基礎上建立的一個網絡底層庫。
閱讀全文
1- 保持內存地址與系統的頁面起始點對齊。
2- 減少小量內存的單獨分配，使用對象池或者內存池進行小量內存的管理。
3- 儘量用系統提供的API進行基於頁面的分配，以提高系統操作和管理內存時的效率。（VIRTUALALLOC）
經過測試，malloc的內存管理沒有直接綁定到頁面。virtualalloc才會直接按照頁面來分配。
測試方法：用Malloc分配4096和4097大小的1024塊內存，從進程管理器中查看內存消耗，並沒有太大區別。
用virtualalloc分配4096和4097大小的1024塊內存，消耗相差近一倍。
分析可知，virtualalloc按照頁面來進行分配，一般頁面大小為4096字節，4097超過1字節會令系統增加一個頁面的分配，從而導致內存使用量攀升近一倍。
同時我們可以得知，malloc的內存分配不會按頁來進行分配，也就是不會進行頁面對齊。
在IOCP應用中，很多時候系統都會鎖用戶內存，鎖內存都是以頁為單位來鎖，沒有對齊過的內存，會導致鎖跨頁面，降低操作的效率，或可造成安全問題。
1- 緊湊或者對齊模式（相當于C/C++結構體的對齊方式）
緊湊模式在持久化時，不考慮字節對齊情況，直接按值類型，按字節持久化。
對齊模式會考慮整體對齊參數，力圖使字段對齊到邊界。
2- 容器本地化或者遠程化
本地化的容器，會共享容器父數據對象的內存。
遠程化的容器，會有單獨的對象內存。
在網絡數據包中，必須使用緊湊模式和本地化容器，以消除所有不確定因素，確保網絡傳輸。
3- 是否持久化索引數據。
索引數據是指對象類中的字段在整個對象類中的索引。在對象類的字段創建開始，這個索引就固定不變，一直到被刪除。所有的字段的索引不可重復。
對象容器中的對象類的字段使用單獨開始的索引。
PROBLEM: 如何在緊湊持久化數據中表示一個容器。（即是否保存容器邊界）