规范标准

Notification Events 通知事件

• Notifications describe a general Publish/Subscribe-Concept. Usually the server publishes a service to which a client subscribes. On certain events the server will send the client a event, which could be for example an updated value or an event that occurred.
  Notification描述了一般的发布/订阅概念。通常，服务器端发布服务而客户端前来订阅。在某些事件上，服务器端向客户端发送event，该event可以是例如更新的值 或者发生的事件。

• SOME/IP is used only for transporting the updated value and not for the publishing and subscription mechanisms. These mechanisms are implemented by SOME/IP-SD.
  SOME / IP仅用于传输更新的值，而不用于发布和订阅机制。这些机制由SOME / IP-SD实现 。

• When more than one subscribed client on the same ECU exists, the system shall handle the replication of notifications in order to save transmissions on the communication medium. This is especially important, when notifications are transported using multicast messages.
  当同一ECU上有多个订阅客户端时，系统应对notification进行复制以便节省通信介质上的传输。当使用多播消息传输通知时，这尤其重要。

Strategy for sending notifications发送notification的策略

For different use cases different strategies for sending notifications are possible and shall be defined in the service interface. The following examples are common:
对于不同的用例，可以使用不同的发送通知策略，并且应在服务接口中定义。 以下是常见的例子： 

• Cyclic update循环更新
  send an updated value in a fixed interval (e.g. every 100 ms for safety relevant messages with Alive).
  以固定间隔发送更新值（例如，每100毫秒用于Alive的安全相关消息）。
• Update on change变化更新
  send an update as soon as a “value” changes (e.g. door open).
  一旦“值”发生变化（例如开门）就发送更新。
• Epsilon change Epsilon更改
  only send an update when the difference to the last value is greater than a certain epsilon. This concept may be adaptive, i.e. the prediction is based on a history; thus, only when the difference between prediction and current value is greater than epsilon an update is transmitted.
  仅当与最后一个值的差异大于某个阈值时才发送更新。 该概念可以是自适应的，比如预测是基于历史值; 因此，只有当预测值和当前值之间的差值大于epsilon时才发送更新。

Fire&Forget Communication

Requests without response message are called fire&forget.
请求但不需要回复的消息成为fire&forget 。

The implementation is basically the same as for Request/Response with the following differences:
其实现基本上和for Request/Response 一样，只有如下的区别:
•There is no response message.
没有response消息。
•The message type is set to REQUEST_NO_RETURN (i.e. 0x01).
message type设置为REQUEST_NO_RETURN (如0x01)。
•Fire & Forget messages shall not return an error. Error handling and return codes shall be implemented by the application when needed.
Fire & Forget消息不能返回error，如果需要的话，error处理和返回值由应用程序实施 。

Request/Response Communication请求/响应通信

One of the most common communication patterns is the request/ response pattern. One communication partner (in the following called the client) sends a request message, which is answered by another communication partner (the server).
最常见的通信模式之一是请求/响应模式。 客户端发送请求消息，服务器端应答。

Client

• Construct the payload
• Set the Message ID based on the method the client wants to call
• Set the Length field
• Optionally set the Request ID to a unique number
• Set the Protocol Version according
• Set the Interface Version according to the interface definition
• Set the Message Type to Request (i.e. 0x00)
• Set the Return Code to 0x00

Server

• builds it header based on the header of the client ,and in addition
• Construct the payload
• Set the length to the 8 Bytes + new payload size
• Set the Message Type to RESPONSE (i.e. 0x80) or ERROR (i.e. 0x81)
• Set the Return Code

Mapping
For the response and error message the IP addresses and port number of the transport protocol shall match the request message.
对于Response和Error message，传输层的IP Address和Port口需要和Request message匹配

Multiple Service-Instances多个服务实例

• Service-Instances of the same Service are identified through different Instance IDs. It shall be supported that multiple Service-Instances reside on different ECUs as well as multiple Service-Instances of one or more Services reside on one single ECU.
  同一服务的多个服务实例通过不同的Instance ID来识别。应支持多个服务实例驻留在不同的ECU上，以及一个或多个服务的多个服务实例驻留在一个ECU上。
• While different Services shall be able to share the same port number of the transport layer protocol used, multiple Service-Instances of the same service on one single ECU shall listen on different ports per Service-Instance.
  虽然不同的服务应能够共享所使用的传输层协议的相同端口号，但是在一个ECU上的同一服务的多个服务实例应在每个服务实例的不同端口上进行侦听。
• Rationale合理性:
  While Instance IDs are used for Service Discovery, they are not contained in the SOME/IP header.
  虽然 Instance ID用于服务发现，但它们不包含在SOME / IP header中。
• A Service Instance can be identified through the combination of the Service ID combined with the socket (i.e. IP-address, transport protocol (UDP/TCP), and port number). It is recommended that instances use the same port number for UDP and TCP. If a service instance uses UDP port x, only this instance of the service and not another instance of the same service should use exactly TCP port x for its services.
  可以通过 Service ID与套接字的组合（即IP地址，传输协议（UDP / TCP）和端口号）来识别服务实例。建议实例对UDP和TCP使用相同的端口号。如果服务实例使用UDP端口x，则只有该服务实例而不是同一服务的另一个实例应该使用TCP端口x作为其服务。

• The TCP binding of SOME/IP is heavily based on the UDP binding. In contrast to the UDP binding, the TCP binding allows much bigger SOME/IP messages and uses the robustness features of TCP (coping with loss, reorder, duplication, etc.).
  SOME / IP的TCP绑定很大程度上基于UDP绑定。 与UDP绑定相比，TCP绑定允许更大的SOME / IP消息并使用TCP的鲁棒性（应对丢失，重新排序，复制等）。
• Every SOME/IP payload shall have its own SOME/IP header.
  每个SOME / IP payload都应具有自己的SOME / IP hearder。
• In order to lower latency and reaction time, Nagle’s algorithm shall be turned off (TCP_NODELAY).
  为了降低延迟和反应时间，应关闭Nagle算法（TCP_NODELAY）。
• When the TCP connection is lost, outstanding requests shall be handled as timeouts. Since TCP handles reliability, additional means of reliability are not needed.
  当TCP连接丢失时，未完成的请求应作为超时处理。 由于TCP的可靠性，因此不需要额外的可靠性手段。
• The client and server shall use a single TCP connection for all methods, events, and notifications of a service instance. When having more than one instance of a service a TCP connection per services instance is needed.
  客户端和服务端应对服务实例的所有method，event和notification使用一个TCP连接。 当具有多个服务实例时，则每个服务实例需要一个TCP连接。
• The TCP connection shall be used for as many services as possible to minimize the number of TCP connections between the client and the server (basically only one connection per TCP port of server).
  TCP连接应该用于尽可能多的服务，以最小化客户端和服务端之间的TCP连接数（基本上每个服务端的TCP端口只有一个连接）。
• The TCP connection shall be opened by the client, when the first method call shall be transport or the client tries to receive the first notifications.
  当发送第一个method调用或者客户端打算接收第一个notification，客户端应该负责打开TCP连接。
• The client is responsible for reestablishing the TCP connection whenever it fails.
  客户端负责在失败时重新建立TCP连接。
• The TCP connection shall be closed by the client, when the TCP connection is not required anymore.
  当不再需要TCP连接时，客户端应关闭TCP连接。
• The TCP connection shall be closed by the client, when all Services using the TCP connections are not available anymore (stopped or timed out).
  当使用TCP连接的所有服务不再可用（停止或超时）时，客户端应关闭TCP连接。
• The server shall not stop the TCP connection when stopping all services the TCP connection was used for but give the client enough time to process the control data to shutdown the TCP connection itself.
  当服务器停止使用某TCP连接的所有服务时，服务器不应停止该TCP连接，但是给客户端足够的时间来处理控制数据以关闭TCP连接。
• Rational合理性:
  When the server closes the TCP connection before the client recognized that the TCP is not needed anymore, the client will try to reestablish the TCP connection.
  当服务器关闭TCP连接而客户端并不清楚不需要该TCP了，客户端将尝试重新建立TCP连接。