skynet 的 1.0 版已經發布了 3 個 alpha 版，等穩定以后將發布 beta 版本。
最近的問題主要集中在一些我們在老項目中沒有使用到的特性上面。尤其是 sproto 這個模塊，我希望它將來作為 skynet 推薦的通訊協議，但我們老的項目開始的比 sproto 的項目早，所以早期項目全部使用的是 google protocol buffers （以及我自己做的實現）。 隨著新項目的開展，我們公司內部開始大面積使用 sproto ，也就發現了一些 bug ，在最近集中修復。
由于 skynet 使用多 lua VM 結構，為了不在每個 VM 里重復加載 sproto 協議，最近增加了 sproto 協議對象的共享。這個作為未寫入 sproto 文檔的特性提供，當然也不影響 sproto 在其它領域的使用。不過加這個特性比較匆忙，第一次提交時在 gc 方面遺留了一個 bug ，有可能導致多個 VM 重復釋放 C 對象，問題已經在倉庫最新的提交中修復。
另一個為了 skynet 的應用而特別加上的特性是讓 sproto 的 decode 可以接收指針（lightuserdata）。固然只接受 string 會讓實現更穩固一些，不過在 skynet 里很多地方 string 和 lightuserdata + size 是通用的，所以就順帶支持了。這樣可以減少一次內存拷貝。
根據使用的同學的需求，在 sproto 的 lua bingding 里增加了更為詳細的出錯提示，這可以幫助實際使用時的錯誤定位。另外，還增加更為嚴格的類型檢查。缺少這些檢查應該算是 bug ，因為使用 sproto 而不是 json 這種的無格式的協議，就是為了可以多做一些類型檢查的。復雜類型（在 lua 里用 table 實現）不檢查還會導致進程掛掉，這是絕對不可以接受的。
最后一個嚴重的 bug 是設計上的。
sproto 的 encode C API 采用的是 callback 的方式。由使用者（通常是其它語言的 binding ）提供一個 callback 函數，C 核心根據 sproto 協議，每個字段調用一次這個函數。
如果它返回 -1 表示編碼錯誤（一般是 buffer 不夠大），會讓 C 核心的編碼過程錯誤返回。
如果它返回 0 表示這個字段不存在。這是因為 sproto 是允許字段不存在的，不存在的字段不會被編碼進最終的串。另外，對數組的編碼也依賴它。如果在編碼一個數組時返回 0 ，表示數組結束。
其它情況應返回一個正數，表示當前需要編碼的對象的長度。
對于簡單類型，如 boolean ，integer ，一般返回的是固定值。boolean 返回 4 ，integer 返回 4 或 8 （提示 C 核心這個整數是 32bit 還是 64bit 的）。最終編碼不一定按這個數字來，且 callback 函數得到的寫入地址也并非最終 buffer 的地址。C 核心會提供一個地址對齊的地址，然后根據 sproto 的編碼協議來轉換到最終 buffer 中，同時還要處理大小端問題。
對于不定長類型，如 string 或自定義類型。這個長度會幫助 C 核心了解應該將 buffer 指針后移多少字節。callback 函數將直接把數據寫入最終的 buffer 。而問題就出在這里。
當 string 是一個空串時，由于空串的長度為 0 ，會讓 C 核心誤會這個字段并不存在，這導致所有的空串無法編碼。更嚴重的是，如果是字符串數組，碰到空串就會停止編碼這個數組。最終的修補方案是，約定在編碼 string 的時候，應該返回字符串長度 + 1 。這屬于一個設計問題，所以除了 lua binding 之外，別的語言的 binding 也需要修改。好在目前已知的 python binding 也是我們公司的同學實現的，應該馬上能改過來。
對于用戶類型，沒有 string 這個問題。即使是空的對象，也有一個數據頭。所以不可能為 0 。對于空對象，不在數組中時，目前的 lua binding 會返回 0 ，讓 C 核心跳過這個字段，而在數組中時，則會返回一個空的數據頭。
利用 sproto 實現的 sharemap 也被查出一個 bug ，不過這個 bug 不屬于 sproto 。它的 metatable 被不小心循環引用了，如果一個字段不存在會導致 lua 檢測出 metatable 循環引用而出錯。
還有一個問題是在使用 httpc 時發現的，雖然已經知道，但因為用的不多也沒有特別在意。這次在正式版發布前，還是給出解決方案：
skynet 的 socket 層在處理域名的時候直接調用了系統 api getaddrinfo ，這會阻塞住線程。由于 skynet 的 socket 是單線程的，所以一旦做域名查詢，會導致 skynet 所有的 socket 消息處理阻塞。一般我們不會使用域名，即使用，也是在數據庫第一次連接的時候，通常發生在 skynet 進程啟動的時候，所以影響不大。但一旦使用 httpc 模塊，就很容易向外連接一個域名了。
由于系統并不提供異步的域名解析方法，很多其它網絡庫的做法是使用額外的線程去查詢域名。我并不想針對這個需求而大幅度修改已經穩定了的 skynet socket 層，所以提供了獨立的解決方案：那就是在上層自己使用 dns 協議發送 udp 包查詢。為了讓 httpc 模塊可以使用它，對其也做了一點改變，允許用戶連接一個 IP 地址，而自己在 http header 里填寫 host 字段。
另外，在充當 http 客戶端時，http 服務器往往會在返回的 header 中填寫多個 Set-Cookie 字段，之前對同名的 header 中字段沒有正確的處理，現在做了修正。（多個同名字段會生成一個 table ）
更多信息請查看IT技術專欄
版權所有:易賢網
公眾號
事業單位
當前位置：
公考類
招聘類
各類考試