Author Archives: Enrico

message – 消息或是訊息，無處不在。Inter-process communication(IPC)中有用shared memory的方式，也有的使用message passing的方式，在物件導向的世界裡物件接收與發送訊息(對應程式語言中method的呼叫)，event driven的程式開發模型更是把訊息當成主角。事實上，我們甚至可以用訊息的觀點(或是模型)來理解這個世界，一切的人事物交互作用都是通過訊息來完成。 message一般可以用header + body(payload)來理解，message header所帶的是與資料內容以外的資訊(如metadata, message property)，而body帶的是資料本身。

在程式語言與資訊系統的世界哩，談到消息免不了要處理序列化的問題，畢竟如果message無法往外傳，這樣的系統等同是處於isolation的狀態。而一封封的message傳輸時，在接收端一般需要另外處理將stream bytes分割，才能還原為一封封的message，因此這時候會需要有消息邊界判定的機制。 消息邊界的判定可分為兩類方式 length prefix 描述消息的長度而知道邊界，下一封消息又往後再用同樣方式讀取，好處是可以預先知道整個消息的長度，缺點是需要知道消息的長度才能傳送(當然，這可由上層的application另外處理來傳送未知長度的消息)，另外是如果因某些原因造成傳輸錯誤而未發現時(即使是TCP error rate也不是0)，可能會造成訊息長度解析錯誤。這類型的作法在很多Message oriented middleware(MOM)，也在DB的wire protocol也常見(如MySQL, MongoDB)，主要原因是相對delimiter，不需要一直掃描內容，解析的效率較高。AMQP的作法也是採用這一種(參考amqp0-9-1) delimiter 分割字元 這種做法就是透過特殊的字元或byte組合來界定邊界，例如HTTP 透過\r\n\r\n 來區分 header, body。另外像H264 NAL也是利用特定的字元組合(start code eg. 00 00 00 01)來作為NAL unit的起始。這個方法的好處是，在設計的當的情況下，可以從消息流的中間開始解析，而不需要從一開始就一字不漏地接收。壞處是需要將整個內容掃過，因為要尋找delimiter並且內容中不能帶有與delimiter相同的位元組合。(若有則需要另外escape，接收時要將內容escaped的資料找出並且還原後再往application層傳) 當然﹐也可以利用delimiter + length prefix的組合來提高解析的效率。

在C++程式語言中，語言本身所提供的資料表示可以用內建基礎型別(primitive type)如整型(integral type e.g. bool, char, int等)、浮點數(float, double)，或是複合型別(array, class, pointer)，但是當需要將程式語言理所表示的資料進行傳輸時，例如傳到磁碟上或是傳到另一個端點時，就會碰到要傳那些資料以及格式的問題，對於基礎型別來說，可以直接將整塊記憶體內容直接儲存傳送(但跨機器時可能會有其他問題，如byte ordering)，對於牽涉到指標型別來說，就沒辦法指複製指標本身的值，而要考慮到所指的內容。物件的內容若牽涉到其他狀態(例如file handle)也沒辦法直接複製記憶體內容，因為這類資訊牽涉到當時的執行環境狀態。如果在重建端無法存取到所描述值的外部系統的狀態，這樣的重建是沒有意義的。 序列化有個最重要的原則: 序列化的資料足以重建回物件的狀態，跨越空間與時間。序列化的內容也可與外部系統相關，但前提是重建時要能夠存取的到，例如儲存DB table的row id，重建端要有辦法存取相關系統，才能還原。 這邊講物件重建回來原來狀態並非指結構上(structural)的值嚴格地完全相同，而是行為上(behavioral)要能夠一致。舉例來說，假如我有一個檔案讀寫的物件，那麼需要重建回物件的狀態使得接下來的操作行為可以與原來相同，這樣序列化至少就需要檔案路徑、開檔模式、讀寫的position offset等，而依照這樣資訊重建回來的物件，物件內部檔案handle的值一般來說不會相同，但對物件的操作結果應該會一致。 對於單純儲存值的物件，可以想成這些值本身就是狀態，我們去get/set value時，在序列化前和還原後行為應該一致。 常見的序列化格式 XML, JSON, Avro, Apache Thrift, Google ProtoBuf 等 在設計上從schema的自我描述、傳輸的效率、版本控制等各有特色。