在《cerl2 系列5：sdl與我對網路協議的思考》一文中，儘管我對 sdl 的來龍去脈做了介紹，但是我發現還是遺漏了非常重要的內容。朋友們可能會問，sdl看起來不就是乙個普通的idl（介面描述語言）嗎，為什麼不直接沿用乙個現成的標準呢？
很多時候，看似相似的東西卻會是貌似神不是。正是因為我覺得idl並不符合我對網路介面協議的觀點，所以才有了 sdl。
首先，多數 idl 都是物件導向的。但是我認為網路協議應該是面向資料流的。為什麼在網路協議中，物件導向是壞的呢？
原因很簡單。物件導向的網路協議必然增加實現的複雜性。由於我們可以在網路流中傳遞物件，那麼自然而然，物件就需要在服務端存在存根（stub），在客戶端存在**（proxy）。而特別讓人討厭的，是物件生命週期的管理。這些都給服務端、客戶端帶來實現難度。如果說加大服務端的複雜度影響不算太大的話，客戶端的難度增加，無疑使得協議的跨語言呼叫變得更加困難。
面向資料流的網路協議很直觀，消除了一切物件導向帶來的負累。我們對在網路中傳遞的資料有著非常清晰的概念。在簡單對協議細節進行了解後，你可以在沒有任何基礎的情形下，很快做出乙個新的語言的客戶端呼叫**。
簡單是美。這是面向資料流的網路協議的魅力所在。
體現 sdl 簡單的另乙個層面，是 sdl 的介面描述方式。對於這樣乙個宣告：
[id=2] get(string key) -> | false;
你可以看到， -> 符號之前的是 request 包，-> 之後的是 response 包。這非常直觀。你可以對比下這樣的乙個宣告：
[id=2] bool get([in] string key, [out] string* val);
兩者的閱讀體驗不是在同乙個檔次上的。
特別是，在 response 的分支情況很多的時候，第二種描述方式就會慘不忍睹。
所以，從各種角度講，sdl 是我認為描述網路協議的介面最佳選擇。
CERL2 系列2 網路程式設計該用同步還是非同步？
在c c 中，libevent boost asio 這兩個網路庫都採用非同步程式設計模型，當io完成事件發生時，呼叫乙個 函式處理它。這種程式設計模型有很好的io吞吐量。但是付出的代價也很大 醜陋的 應用程式邏輯被乙個個 函式切割得支離破碎。複雜的記憶體管理。乙個不小心，就有可能出現 函式執行的時...
winhex系列2 sd卡格式化
sd格式化型別基本分為 1.低階格式化，按照網上的說法，在sd卡出廠前，廠商會對sd卡進行低格操作，將sd卡內容全部置為0，這時sd卡內部沒有任何資料 2.普通格式化 高階格式化的一種 會將sd卡資料區清0，這種在我拿一張sd卡在win7作業系統上格式化 不選快速格式化 的情況下，實測資料區確實全部...
2018SD省隊集訓R2 D6
這是一道簽到題 考慮入度出度平衡的狀態，我們先把所有的邊減成0，然後考慮對於一條有向邊x y，如果有c個，那麼可以連權值為 w，流量為c的，還要連權值是w，流量為inf的，我們從1跑到n的時候，考慮什麼時候dis t 0的時候就結束了，再走下去不會更優 include include include...