前面的文章给大家介绍了SOME/IP的功能、标准和报文格式，接下来我们开始介绍更多和实际应用相关的内容。首先，是通信方式。看看SOME/IP是如何通信的，节点之间是如何通过SOME/IP进行交互的。

在SOME/IP中，一共有三种通信方式，分别是Method、Event和Field。

Method有两种类型，Request/Response（RR）和Fire&Forget（FF），Request/Response即请求/响应，是最常见的，Client（客户端）发送请求，Server（服务器）回复响应，属于同步调用，对应的报文类型为0x00 REQUEST（报文类型在上篇文章中有介绍）和0x80 RESPONSE。Fire&Forget，可以直译成点火即忘，触发了但不在乎结果，Client发送请求，但不需要服务器的响应，属于异步调用，对应的报文类型为0x01 REQUEST_NO_RETURN，如下图。 当需要等待Server响应时，比如需要Server中的某些数据、信息，或者需要获取请求的执行结果等，都可以使用Request/Response，意味着发出请求后，需要等待响应。而当只需要将请求发送到Server，而不需要对方的响应时，可以使用Fire&Forget，发送请求后，可继续执行下面的操作，无需等待响应。相比较而言，Request/Response的可靠性和数据一致性更高，因为请求和响应是一一对应的，如果发现响应错误或超时，可以采取一些处理措施。而Fire&Forget的优势则在于可以节省时间和资源，同时无需等待也可以提高系统的响应速度。在实际设计中，需要根据具体的功能需求和系统性能来选择合适的Method类型。

举个例子，【场景一】Client想获取Server端的网络配置信息，【场景二】Client想将自己的错误日志发送给Server，这两个场景中，【场景一】可以使用Request/Response，因为需要Server返回信息，当Server接收到请求后，可以通过响应来传输。而【场景二】可以使用Fire&Forget，对于Client来说，只需要把错误日志发送给Server即可。

Event为事件类型，基于发布/订阅的机制，是当Client订阅了某个事件组后，在该事件发生时，Server发送通知给Client的通信方式，报文类型为0x02 NOTIFICATION，如下图。 图中Event报文上方还有两个SD报文，SD是服务发现Service Discovery，也是SOME/IP的一个模块，Event类型通信的前提是通过SOME/IP SD进行发布和订阅，SD会在后面的文章中详细介绍，本文主要介绍用于数据传输的SOME/IP协议。在SOME/IP中，定义了三种通知发送的策略：

大家都会用银行卡，无论是储蓄卡还是信用卡，都有消费提醒和余额或者额度查询的服务。

银行会定期给我们发送账单，比如信用卡账单，都是固定在每个月的某一天，叫做账单日。无论账户是否有变动，无论这个月的消费金额是多还是少，银行都会按照既定的周期发送账单。这就是Cyclic update，周期发送策略。

如果设置了消费提醒服务（专业点叫储蓄/信用卡账户变动通知），每当账户发生变动时，比如消费、发工资后，就会收到一条通知信息，告诉我们账户变动的时间、对方账户和金额。这就是Update on change，发生变化后发送。

如果设置的账户变动通知服务可以选择通知起点金额，那么每当账户发生变动时，只有变动金额超过起点金额，才会收到通知信息。比如设置的起点金额是500，当账户变化小于500时，不会有通知，只有金额大于500时才会通知。这就是Epsilon change，变化超过一定阈值时，才会发送。

为了更好地理解，我们继续举个请求/响应的例子，假如我们想主动查询下储蓄卡的余额或者信用卡的额度，通常会发送一条查询请求给银行，然后银行回复我们余额或者额度等信息，这一来一回就是Request/Response的通信方式。 以上四种，前三种都需要预先设置，可以类比为SOME/IP中需要预先通过SOME/IP SD进行订阅，而最后一种只需要在想获取信息的时候主动请求即可。

最后一种通信方式叫Field，可以用来表示具体的“属性”，比如状态、模式或者数值等。Field是一个合集，里面包含了Getter、Setter和Notifier三种方式，Client可以用Getter去主动获取，可以用Setter去设置，也支持当满足一定触发条件时，Server主动发出通知，即Notifer。定义Filed时，可以选择只包含Getter、Setter还是Notifer，或者包含其中两个以及全部。

今天就先分享到这，本文介绍了SOME/IP如何通信，下一篇文章将会继续介绍SOME/IP的数据类型和格式。