【someip報文格式部分字段概述】
message id是乙個32位識別符號，用於將rpc呼叫分派給應用程式的method並識別event 。 message id必須能唯一標識service的method或event。
message id的分配取決於使用者; 然而，對於整個系統（即車輛），訊息id必須是唯一的。 訊息id可以與can id進行比較，並且應該使用類似的過程進行處理。
為了構造不同的method， event和field ，它們被聚集到service中。 service具有一組method ， event和field以及services id，該id僅用於此service。
service-id應該是16位長度無符號整數（uint16）。 service-id=0xfffe用來編碼非some / ip服務。同一車輛內的不同服務應具有不同的service-id。
method和event應在service內部使用16位method id來識別，對event和notification來說，稱為event id。
request id允許客戶端區分相同的method的多個call 。 request id對於客戶端和伺服器的乙個組合來說，需要時唯一的。 在生成響應訊息時，伺服器必須將請求中的request id複製到response訊息中。 這允許客戶將響應對映到發出的請求，即使有多個請求未完成。
只要響應已經接收到或者不再期望這個響應（超時），就可以重新使用request id。 在汽車使用案例中，只有很少數量的未完成的請求在被繼續等待。 小型系統裡在沒有並行請求的可能性的情況下， request id可能總是設定為相同的值。
在autosar 架構下, request id需要結構化。 即使對於非autosar系統，也需要對呼叫者的客戶端id進行編碼。
request id包含client id 和session id。
ecu的實施者可以按照他的實施要求來定義client id，並且伺服器不需要知道這個布局或定義，因為他只是將整個request-id複製到response中。
client id是ecu內call客戶端的唯一識別符號。 session id是客戶端為每個call選擇的唯一識別符號。 如果不需要進行session處理，則session id應設定為0x0000。
client id還應通過具有可配置字首或固定值支援其在整個車輛中唯一性（例如，client id的最高位是診斷位址或為特定應用程式/swc配置專門client id)。
注意： client id不用於service discovery。
request/response method需要使用以id以0x0001開頭的session 來處理。
event, notification event和fire&forget methods 需要使用session處理，如果應用需要的話。比如因為功能安全的需要。
對於events,notification events,和 fire&forget methods ,session id需要以0x0001開頭，且每次message發出的時候遞增。
當session id達到0xffff,則其回到0x0001重新開始。
【version】
protocol version是乙個8位欄位，其中包含some/ip的協議版本，目前應該被設定為0x01 。
inte***ce version 是乙個8位欄位，其中包含service inte***ce的major version 。
【message type】
message type用來區別不同型別的message，且應當包含如下的值：
常規request(訊息型別0x00)將在未發生錯誤時由response(訊息型別0x80)應答。如果發生錯誤，則會傳送error訊息(訊息型別0x81)。 也可以傳送不需要響應訊息的請求(訊息型別0x01)。為了通過notification更新值，存在乙個callback介面(訊息型別0x02)。
對於所有訊息，存在可選的acknowledgment 報文(ack) 。 這是為那些並不告知收到訊息的某些傳輸層協議(如udp)而定義的。 ack只在inte***ce specification要求時才被傳輸。 本文件中僅規定了request_ack的用法。 所有其他ack現在都是資訊性的，不需要實施。
【return code】
return code用於表示request是否已成功處理。 為了簡化header布局，每條訊息都傳輸return**。
型別為request, request_no_return和notification的訊息必須將返回碼設定為0x00（e_ok）。 允許的特定訊息型別的返回碼是：
注意：return code不適用於some / ip-sd。
【payload】
some / ip payload欄位的大小取決於使用的傳輸協議。 對於udp，some / ip有效載荷應該在0到1400位元組之間。限制為1400位元組是為了允許將來對協議棧進行更改（例如更改為ipv6或新增安全機制）。 由於tcp支援有效載荷的分段，所以自動支援更大的尺寸。
mysql報文格式 Mysql 報文格式
mysql client和server端之間的的資料根據不同的協議規則的進行組織傳送。每包資料在傳送的時候都要新增上協議頭。mysql原始碼採用5.7.10版本 協議頭 每個協議頭共4個位元組 包資料長度 前三個位元組表示資料部分的長度 不包括協議頭 三位元組能表示的最大長度是16m 1 2 24 ...
mysql報文格式 Mysql 報文格式
mysql client和server端之間的的資料根據不同的協議規則的進行組織傳送。每包資料在傳送的時候都要新增上協議頭。mysql原始碼採用5.7.10版本 協議頭 每個協議頭共4個位元組 包資料長度 前三個位元組表示資料部分的長度 不包括協議頭 三位元組能表示的最大長度是16m 1 2 24 ...
TCP報文格式 UDP報文格式 MAC幀格式
tcp和udp的區別 1 tcp是面向連線的，而udp是無連線的 2 tcp提供可靠服務，而udp不提供可靠服務，只是盡最大努力交付報文 3 tcp面向位元組流，tcp把資料看成一串無結構的位元組流，而udp是面向報文的 udp資料報 ip頭部 ip資料報 4 tcp有擁塞控制，udp沒有擁塞控制 ...