prp协议原理解析

prp协议标准

prp协议总体架构

prp配置方法

insmod hsr.ko

prp初始化

在调用ip link 创建虚拟网卡prp0时会最终进入hsr_dev_finalize函数，并根据指定的协议选择操作集函数此处为prp_ops。

此处即是将实际的物理网卡p3p1和物理网卡p2p1以及虚拟网卡prp0挂载到hsr->ports链表中。其中HSR_PT_SLAVE_A和HSR_PT_SLAVE_B代表网络网卡对应的struct hsr_port。HSR_PT_MASTER则代表虚拟网卡prp0对应的struct hsr_port。

在调用hsr_add_port函数进行添加时，很重要一点，对实际的物理网卡会调用hsr_portdev_setup注册了网卡收到报文时的钩子函数hsr_handle_frame。

而在网卡收到报文进行网络协议栈处理前会调用__netif_receive_skb_core函数，并在次函数中调用上文说到的钩子函数hsr_handle_frame。
返回值含义：
RX_HANDLER_CONSUMED：表示接收处理程序（RX handler）已经完全处理了接收数据，并且不需要将数据传递给其他处理程序。换句话说，接收处理程序已经消费了接收数据，不再需要其他处理程序进一步处理它。通常，在这种情况下，数据已被处理或丢弃，并且不需要额外的处理。
RX_HANDLER_ANOTHER：表示接收处理程序已经处理了接收数据的一部分，但仍然希望将其传递给另一个处理程序进行进一步处理。这种情况下，接收处理程序已经对数据进行了一些处理，但是需要其他处理程序参与，可能是因为接收数据具有多个层次的处理需求。
RX_HANDLER_EXACT：表示接收处理程序已经完全处理了接收数据，并且数据不需要进一步传递给其他处理程序。与 RX_HANDLER_CONSUMED 类似，但是 RX_HANDLER_EXACT 表示接收处理程序对数据的处理是准确的，没有发生任何丢失或修改。
RX_HANDLER_PASS：表示接收处理程序将接收数据传递给了另一个处理程序，并且不对数据进行任何处理。接收处理程序不会修改数据，而是将其原样传递给其他处理程序。在这种情况下，接收处理程序只是将数据转发给其他处理程序，而不对数据本身进行任何操作。

tcpdump接收报文抓包：

但是__netif_receive_skb_core函数中遍历ptype_all在执行rx_handler(&skb)之前。且tcpdump抓包接收报文的原理即是注册struct packet_type到ptype_all链表中。所以即使后面prp协议会丢弃重复报文，也依然可以被tcpdump抓到报文。

prp报文发送原理

对于发送报文时会首先找到虚拟主设备struct hsr_port，即prp0虚拟网络接口。随后进入hsr_forward_skb函数进行报文的转发。

在hsr_forward_do函数中会遍历挂载在此prp0接口上的所有struct hsr_port结构体，并且会根据不同的情况进行判断并进行continue；


最终会调用dev_queue_xmit函数将实际的报文发送出去。即实际的物理网卡p3p1和物理网卡p2p1以及虚拟网卡prp0都会挂载到struct hsr_priv *hsr->ports链表中，遍历到实际的物理网卡时即调用hsr->proto_ops->create_tagged_frame(frame, port);函数克隆一个skb，并最终将此skb传递给网卡进行实际的报文发送。
在hsr_forward_do函数调用完成之后对虚拟网卡prp0的报文发送进行计数
port->dev->stats.tx_packets++;
port->dev->stats.tx_bytes += skb->len;
并且原始的struct sk_buff *skb都会被释放。 kfree_skb(frame.skb_hsr);
kfree_skb(frame.skb_prp);
kfree_skb(frame.skb_std);

prp报文接收原理

上文提到的钩子函数hsr_handle_frame中最终会调用hsr_forward_skb进行报文转发判断，并且正常情况下返回值为RX_HANDLER_CONSUMED即在__netif_receive_skb_core函数中不会再处理该报文。


在hsr_forward_do函数的while循环中会调用hsr_register_frame_out函数进行报文的去重判断，如果报文重复则返回1即在上述while循环中continue;。其判断方法就是当前收到报文的序列号是否大于已收到报文的序列号(发送端同一个报文会由两个网络接口发出，其序列号也是一样的)，通过这样一种方式去掉重复的报文。（此处存在优化空间）

对于没有重复的报文则会调用hsr_deliver_master函数将此报文转发给虚拟网卡prp0。上文提到只有实际的物理网卡会注册rx回调函数hsr_handle_frame。所以此处转发给虚拟网卡的报文会正常进入到内核网络协议栈进行处理。

还有需要注意的一点是两个网卡会接收到通一个报文，即通一个报文会在不同的网卡rx回调函数中进入两次hsr_forward_do进行struct hsr_port的遍历。但是只有没重复的报文且port->type == HSR_PT_MASTER才会进入到hsr_deliver_master转发给上层协议栈。

总结

PRP协议通过使用两个冗余的并行路径和冗余检查机制，提供了实时以太网网络的高可靠性和容错性。它可以在链路故障发生时快速切换到冗余路径，确保数据的可靠传输。PRP协议的独立性使其能够与各种上层协议兼容，并广泛应用于工业控制系统、电力系统、交通系统等对通信可靠性要求较高的领域。

使用：
1.PRP协议主要应用于实时工业以太网领域，用于提供高可靠性的通信。
2.PRP协议通过在物理层上提供两个冗余的并行网络路径来实现冗余性。每个路径都有独立的链路、交换机和设备。
3.PRP协议不依赖于网络层或传输层协议，因此可以与各种上层协议（如TCP/IP）兼容。

原理：
1.PRP协议使用了两个并行路径，称为Path A和Path B。每个路径都包含独立的链路和设备，形成了一个冗余的网络结构。
发送端将数据同时发送到Path A和Path B上的接收端。这两个路径独立工作，没有相互通信或同步需求。
2.接收端从Path A和Path B接收数据，并使用冗余检查机制进行数据校验。如果某个路径上的数据被破坏或丢失，接收端可以从另一个路径上获取正确的数据。
3.接收端根据冗余检查的结果选择正确的数据，并将其传递给上层应用或协议进行处理。
4.PRP协议具有快速的故障切换能力。如果某个路径上发生故障，接收端可以立即切换到另一个路径上继续接收数据，实现无缝的冗余转换。