DoIP专栏 - DoIP协议组成

一. 概述

该小节主要介绍DoIP报文的接收方法及其协议格式，对协议格式的组成有所了解后，后续章节会对协议的解析及异常处理进行讲解。

二. 正文

2.1 端口号
从DoIP名字可以看出，该协议是在TCP/IP之上的，那么要想接收DoIP协议的报文，协议书规定需要监听一个专门分配给
DoIP协议栈使用的端口号即13400，UDP，TCP都要监听此接受端口，而发送端口是在一个范围内的随机值[49152~65535],
当然代码中协议栈要对对端的发送端口进行缓存，用于回送数据。

指定了端口号，客户端和服务端可以在此端口上进行收发数据。那么对该端口收到的数据是否真的是DoIP报文，就行对该网络报文进行解析。
（有可能是网络攻击，有可能是其它应用恰好使用了该端口号）
对收到的报文进行解析，就涉及到DoIP协议的构成，只有符合该写一点规范才认为是合法有效的DoIP报文。

2.2 协议格式
DoIP报文由协议头（header）+ 负载（payload）组成
协议头[8 byte]由下面四个字段组成
Protocol version [1 byte]
Inverse protocol version [1 byte]
Payload type [2 byte]
Payload length [4 byte]
负载[N byte] 根据实际的payload type，负载数据会不同

2.3 Protocol version与Inverse protocol version
通常Protocol version为0x02，目前0x02以上的值目前是reserved状态
Inverse protocol version是Protocol version的取反的值，此例0x02去反后为0xFD
协议书上特别说明了Protocol version可以为0xFF，设这个值的作用是，当客户端和服务端的协议版本不匹配，
可以设置此值绕过协议头版本不匹配而拒绝请求的case。

2.4 Payload type
payload type可以代表DoIP协议栈所能支持的功能，列举如下（特意分开了Server支持的type及Client支持的type）

                                        DoIP Server

                                        DoIP Client

如上分开描述，是因为在代码实现上，可以将逻辑拆分。
即Server端只关心自己支持的payload type，客户端只关心自己支持的payload type，不支持的可以忽视掉。
有利于模块拆分及组合，有利于实现上一节所讲个各个角色，将来通过配置文件的配置，来表示不同的角色。

2.5 Payload length
payload length这里分配了4字节，也就是所DoIP报文最大传输4 GB /4294967295 bytes，即0xFFFFFFFF。
那么实际情况真的会传输这么大数据吗？我是没见过...
它只是个允许的范围，通常来说通过DoIP进行诊断也就几字节到几十字节，而升级通常ECU的升级包也就几MB。
所以4 GB只是个理论上限。

那么另一个问题，payload length有什么用？仅仅的告诉后续payload有多长吗？
其实该值可以做长度的有效性验证，因为除了诊断数据，其它payload type都是有固定长度的。
还可以做什么？其实做开发时还要考虑遇到如下情况该怎么处理
1. 数据粘连
2. 数据截断
3. 异常的超大size
4. 超过协议栈可以处理size
等等，如果遇到过关于payload length其它一些异常情况，可以进行交流

2.6 Payload
这里的负载是指的是DoIP协议的负载，当然当Payload type为诊断类型时，其负载除了DoIP自身的内容，
还包含了UDS数据，供上层UDS模块进行进一步的解析。
因为每个Payload type负载都不同，这里不做解释，在后续功能章节，进行详细的介绍

二. 结语

以上针对协议的组成部分进行介绍，如有疑问可以进行留言，后续将开始讲解具体的功能部分。