补充：以 ptp4l、E2E 为例的 Linuxptp 代码分析

最近仍然在看linuxptp的问题，对其代码做了更深的了解，下面补充一些知识点。详细文章需要参考上一篇：以 ptp4l、E2E 为例的 Linuxptp 代码分析

1 Event message and General message

我是由于研究第二点才发现的第一点，有个先后顺序。关于这两种message，通过Google我找到了以下的解释。

Event messages are timed messages in which an accurate timestamp is generated at both transmit and receive time. General messages do not require accurate timestamps.

Event messages是有时间的消息，发送和接收时间都会生成准确的时间戳。 General messages不需要准确的时间戳。

借助下面的图我们分析一下E2E。下面的图是一个 E2E 的示例。从图中我们可以看到第一步Sync，发送它和接收它都会生成时间戳，即 t1 以及 t2，所以他是 event msg。而随后的 follow up，它只是携带了 t1，所以它是 general msg。同样的，delay req 是 event msg，而 delay resp 是 general msg。 

2 关于UDP Port

通过wiki我们可以看到下面两点，在 UDP 的 port 中，319和320用于两种类型的 msg。

Port	Description
319	Precision Time Protocol (PTP) event messages
320	Precision Time Protocol (PTP) general messages

根据上面的分类，可以知道 sync msg 应该是 port 319 而 follow up msg 应该是 port 320，下面抓了两个包验证了一下，确实如此。

sync msg

follow up msg

3 ptp4l E2E code

基于以上两点，对于 ptp4l E2E 部分的 code 我们会有一个新的认识，如果加到上一篇文章中，会显得过于杂乱，所以在这里单独记录一下。以下两部分，对照上一篇可以有一个更深刻的认识。

3.1 master 端

首先 fd_index 会等于6，即 FD_MANNO_TIMER，进而执行 port_tx_announce，发出 announce msg。

其次 fd_index 会等于7，即 FD_SYNC_TX_TIMER，进而执行 port_tx_sync，发出 sync msg 以及 follow up。

在收到 slave 端发送的 delay req msg 后， fd_index 会等于0，即 FD_EVENT，随后执行 process_delay_req 发送 delay resp msg。

3.2 slave 端

首先 fd_index 会等于0，即 FD_EVENT，随后执行 process_sync 处理收到的 sync msg。

然后 fd_index 会等于1，即 FD_GENERAL，随后执行 process_follow_up 处理收到的 follow up msg。

接着 fd_index 会等于2，即 FD_DELAY_TIMER，进而执行 port_delay_request 发送 delay req msg。

最后 fd_index 会等于1，即 FD_GENERAL，随后执行 process_delay_resp 处理收到的 delay resp msg。

这篇是一些补充，后续如果还有其他内容的话我会直接在这篇文章后面补充。

如果觉得这篇文章有用的话，可以点赞、评论或者收藏，万分感谢，goodbye~