在程式語言與資訊系統的世界哩，談到消息免不了要處理序列化的問題，畢竟如果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的組合來提高解析的效率。