Offline identification method based on SOA communication and electronic equipment

Abstract

The invention relates to the technical field of communication, in particular to an offline identification method based on SOA communication and electronic equipment for implementing the method. An execution main body of the method is a client or a server, and the method comprises the following steps: in response to online or restarting, clearing locally stored session information; storing an IP address and a port number of an opposite terminal currently establishing SOA communication with the terminal; a heartbeat session for the IP address and the port number is established, a heartbeat session identifier determined by negotiation with the opposite terminal is stored, and the heartbeat session identifier is used for uniquely identifying the heartbeat session established this time; periodically sending a heartbeat packet to the IP address and the port number, wherein the heartbeat packet comprises a heartbeat session identifier determined by negotiation; and determining that the opposite terminal is offline in response to a first response received from the receiving party of the heartbeat packet, wherein the first response indicates that the receiving party cannot find information matched with the heartbeat session identifier included in the heartbeat packet in the session information stored locally.

Description

Technical Field

[0001] The present application relates to the field of communication technology, and more specifically to an offline identification method based on SOA communication and an electronic device implementing the method. Background Art

[0002] With the rapid development of automobile intelligence and networking, vehicle-mounted SOA (Service-Oriented Architecture) communication technology has become the cornerstone for efficient and flexible information exchange between vehicle components. In the complex and ever-changing vehicle operating environment, SOA communication subjects may temporarily or permanently lose communication capabilities due to sleep, restart or failure, that is, "go offline". Considering the requirements of vehicle-mounted systems for real-time and reliability, it is crucial to quickly and accurately identify the offline status of communication subjects and take recovery measures in a timely manner to ensure the safety and stability of vehicle operation.

[0003] The traditional heartbeat detection mechanism is mainly based on the continuous loss of multiple heartbeat packets as the basis for determining that the other party is offline. Although this method can detect the offline status of the other party, it has the problem of long detection delay and is difficult to meet the needs of rapid response. In addition, when the communication subject is quickly restarted in a short time (for example, the interval between sending a heartbeat packet), the traditional heartbeat detection mechanism often cannot capture that the other party has experienced an offline state, resulting in the inability to take recovery measures in time.

[0004] It should be noted that the information disclosed in the above background technology section is only used to enhance the understanding of the background of the present application, and therefore may include information that does not constitute the prior art known to ordinary technicians in the field. Summary of the invention

[0005] In order to solve or at least alleviate one or more of the above problems, the present application provides an offline identification method based on SOA communication and an electronic device implementing the method, which can quickly and accurately identify the offline status of the SOA communication subject, thereby improving the security and stability of SOA communication.

[0006] According to a first aspect of the present application, a method for offline identification based on SOA communication is provided, the execution subject of the method is a client or a server, and the method includes the following steps: in response to going online or restarting, clearing locally stored session information; storing the IP address and port number of the opposite end with which SOA communication is currently established; establishing a heartbeat session for the IP address and port number, storing a heartbeat session identifier determined by negotiation with the opposite end, the heartbeat session identifier being used to uniquely identify the heartbeat session established this time; periodically sending a heartbeat packet to the IP address and port number, wherein the heartbeat packet includes the negotiated heartbeat session identifier; and determining that the opposite end has gone offline in response to receiving a first response from a recipient of the heartbeat packet, wherein the first response indicates that the recipient cannot find information matching the heartbeat session identifier included in the heartbeat packet in its locally stored session information.

[0007] As an alternative or supplement to the above scheme, in an offline identification method based on SOA communication according to an embodiment of the present application, the first response is generated by the receiving party under the following circumstances: the peer end has gone offline and the IP address and port number are occupied by the receiving party, and the receiving party is not the peer end.

[0008] As an alternative or supplement to the above scheme, in an offline identification method based on SOA communication according to an embodiment of the present application, the first response is generated by the recipient under the following circumstances: the counterpart has cleared the locally stored session information after restarting and continues to use the IP address and port number, where the counterpart is the recipient.

[0009] As an alternative or supplement to the above solution, in an offline identification method based on SOA communication according to an embodiment of the present application, the heartbeat session identifier is generated by the client and sent to the server.

[0010] As an alternative or supplement to the above solution, the offline identification method based on SOA communication according to an embodiment of the present application also includes: when the heartbeat packet cannot be routed to the IP address and port number, determining that the other end is offline.

[0011] As an alternative or supplement to the above scheme, the offline identification method based on SOA communication according to an embodiment of the present application also includes: in response to establishing a SOA communication connection with the peer end, locally storing the context of the peer end, the context including the IP address, port number and session information related to the IP address and port number of the peer end, wherein the session information includes the heartbeat session identifier.

[0012] As an alternative or supplement to the above scheme, the offline identification method based on SOA communication according to an embodiment of the present application also includes: in response to receiving the first response, deleting all sessions established for the opposite end; re-establishing a heartbeat session for the IP address and port number, storing a new heartbeat session identifier negotiated and determined with the receiving party; and periodically sending heartbeat packets to the IP address and port number, wherein the heartbeat packets include the new heartbeat session identifier.

[0013] According to the second aspect of the present application, an electronic device is provided, comprising: a memory; a processor; and a computer program stored in the memory and executable on the processor, wherein the execution of the computer program enables any one of the offline identification methods described in the first aspect of the present application to be executed.

[0014] As an alternative or supplement to the above solution, the electronic device according to an embodiment of the present application is a vehicle.

[0015] According to one or more embodiments of the present application, the offline identification scheme based on SOA communication improves the real-time and accuracy of offline identification of SOA communication subjects through technical means such as timely clearing local session information, negotiating a unique heartbeat session identifier, including the heartbeat session identifier in the heartbeat packet, and making offline determinations based on the heartbeat session identifier, thereby improving the security and stability of SOA communication.

[0016] Specifically, the solution can quickly identify the offline of the communication subject, significantly improving the detection delay problem of the traditional heartbeat detection mechanism, thereby meeting the real-time requirements. On the other hand, the solution solves the problem that the traditional heartbeat detection mechanism cannot capture fast restarts, thereby improving the accuracy of offline identification. BRIEF DESCRIPTION OF THE DRAWINGS

[0017] The above and / or other aspects and advantages of the present application will become clearer and easier to understand through the following description of various aspects in conjunction with the accompanying drawings, in which the same or similar units are represented by the same reference numerals. In the accompanying drawings:

[0018] Figure 1 is a schematic flow chart of an offline identification method 10 according to one or more embodiments of the present application;

[0019] Figure 2 A schematic diagram of an SOA communication architecture according to one or more embodiments of the present application;

[0020] Figure 3 is a schematic block diagram of an electronic device 30 according to one or more embodiments of the present application. DETAILED DESCRIPTION

[0021] The description of the following specific embodiments is merely exemplary in nature and is not intended to limit the disclosed technology or the application and use of the disclosed technology. In addition, it is not intended to be bound by any express or implied theory presented in the aforementioned technical field, background technology or the following specific embodiments.

[0022] In the following detailed description of the embodiments, many specific details are set forth in order to provide a more thorough understanding of the disclosed technology. However, it is apparent to one of ordinary skill in the art that the disclosed technology can be practiced without these specific details. In other instances, well-known features are not described in detail to avoid unnecessarily complicating the description.

[0023] Terms such as "comprising" and "including" indicate that in addition to the units and steps directly and clearly stated in the specification, the technical solution of the present application does not exclude the situation of having other units and steps that are not directly or clearly stated. Terms such as "first" and "second" do not indicate the order of units in terms of time, space, size, etc., but are only used to distinguish between units.

[0024] First, some basic concepts involved in this application are introduced.

[0025] SOA is a software architecture that organizes functions according to business processes and encapsulates functions into interoperable services. The main bodies of SOA communication include clients and servers, which exchange data and call services through standard network protocols. Under the SOA communication architecture, the client is the requester of data or services, and the server is the provider of data or services. The client triggers the execution of the target business by sending a business request to the server. Specifically, in the SOA communication process, the client uses the IP (Internet Protocol) address and port number provided by the server as the communication identifier to ensure that the business request can be accurately sent to the server. Once the business request is received and processed by the server, the server returns the result to the client, and the client then processes these responses to complete the business logic.

[0026] In particular, in the vehicle SOA communication environment, the client can be any ECU (Electronic Control Unit), domain controller or CPU (Central Processing Unit) that needs to request data or call services. The server can be an ECU, domain controller, CPU or cloud service provider that provides data or services (for example, motor control, brake control, etc.).

[0027] The term "session" in this article refers to a connection between a client and a server for data exchange and service calls.

[0028] Hereinafter, various exemplary embodiments according to the present application will be described in detail with reference to the accompanying drawings.

[0029] Referring to the accompanying drawings, Figure 1 The schematic flow chart of the offline identification method 10 according to one or more embodiments of the present application is shown in FIG. It should be noted that the execution subject of the offline identification method 10 is the SOA communication subject, that is, it can be either a client or a server. When the client is the execution subject, the other end with which SOA communication is established is the server; when the server is the execution subject, the other end with which SOA communication is established is the client.

[0030] like Figure 1 As shown, in step S110, in response to going online or restarting, the locally stored session information is cleared.

[0031] Session information refers to temporary data generated during the interaction between the client and the server, which may include any one or a combination of session identification, permission and access control, user authentication information, etc. This data is stored in the local storage (e.g., memory, database, or cache) of the client and server so that it can be quickly accessed during the session.

[0032] In the offline identification scheme according to the present application, the SOA communication between the client and the server relies on a dynamically assigned IP address or port number. In one possible scenario, the client or server is not restarted after going offline, and the IP address and port number used before going offline (hereinafter referred to as the "old IP address and port number") may be occupied by another client or server. In another possible scenario, the client or server uses a new IP address and port number after restarting. Such scenarios can be divided into two situations: its old IP address and port number are occupied by other clients or servers; or its old IP address and port number are not occupied by other clients or servers. It should be noted that the "restart" in this application includes both quick online after going offline (that is, quick restart), and also includes the situation where the client goes online again after a certain time interval after going offline.

[0033] It is understandable that, due to the existence of the above-mentioned dynamic allocation mechanism, the client or server may have changed to another new identity after restarting or going online (for example, the ECU performing motor control occupies the old IP address and port number of the ECU performing brake control after going online), and its subsequent interaction may have nothing to do with the old identity. In view of this, step S110 is intended to ensure that the client or server can start a new session in a "clean" state after each restart by clearing the local session information in a timely manner, without being interfered by the old session information.

[0034] In step S120, the IP address and port number of the peer with which the SOA communication is currently established are stored.

[0035] Storing the IP address and port number of the other end is the basis for the two communicating parties to establish and maintain a session. Specifically, the IP address refers to the unique identifier assigned to the SOA communication subject in the network. The port number refers to the identifier used to identify a specific service or application on the SOA communication subject, which is used to distinguish different services or applications running on the same SOA communication subject.

[0036] In some possible implementations, the client and the server obtain the IP address and port number of the other party through the service registration and discovery mechanism. In such implementations, the server registers its IP address, port number and service information provided to the service registration center after going online; when the client needs to call a service, it queries the service registration center for the IP address and port number corresponding to the target service; after obtaining the IP address and port number, the client uses a network communication protocol (for example, HTTP, HTTPS, TCP, UDP, etc.) to establish a connection with the server; during the connection establishment process, the client and the server can exchange necessary information (for example, configuration information, IP address and port number) to ensure that each communication subject can correctly identify the other party and is ready for business interaction.

[0037] Optionally, after obtaining the IP address and port number of the server, the client can create a container or object locally for storing the context related to the server, referred to as "ServerContext" in this article. Correspondingly, the server also creates a container or object locally for storing the context related to the client, referred to as "ClientContext" in this article. Exemplarily, ServerContext and ClientContext are used to store the IP address, port number and session information related to the IP address and port number of the other party (for example, the heartbeat session identifier and / or business session identifier to be introduced below). It can be understood that ServerContext and ClientContext are only associated with the current IP address and port number of the other party. This means that if the other party goes offline and its old IP address and port number are occupied by other communication subjects, the context stored in ServerContext or ClientContext will not be applicable to the communication subject. In this regard, after the client or server obtains the IP address and port number of the other party through the service registration and discovery mechanism, it can be checked locally whether there is a ServerContext or ClientContext related to the IP address and port number. If so, the old ServerContext or ClientContext is deleted and a new ServerContext or ClientContext is recreated locally.

[0038] As mentioned above, the heartbeat detection mechanism is used to monitor the online or offline status of both communicating parties. However, the traditional heartbeat detection mechanism has the problem of long detection delay and inability to capture fast restart. In view of this, steps S130-S150 are intended to provide an improved heartbeat detection mechanism to achieve fast and accurate identification of the offline of the other end, thereby solving or at least alleviating the above problems.

[0039] In step S130, a heartbeat session for the IP address and port number is established, and a heartbeat session identifier determined by negotiation with the peer end is stored.

[0040] A heartbeat session refers to a connection established between a client and a server to realize the sending and receiving of heartbeat packets. In particular, a unique identification identifier is determined for each heartbeat session established according to the improved heartbeat detection mechanism of the present application, which is called a heartbeat session identifier (ID). In order to ensure the uniqueness of the heartbeat session ID, the client and the server determine the heartbeat session ID by negotiation. Normally, the heartbeat session ID is generated by the client and sent to the server using the established heartbeat session to achieve synchronization of the heartbeat session ID on both sides. In a possible implementation, the client can use UUID (Universally Unique Identifier) ​​to generate the heartbeat session ID. In another possible implementation, a central session manager can be used to allocate the heartbeat session ID, and this central session manager can ensure that each ID generated by it is only allocated once.

[0041] In step S140, a heartbeat packet is periodically sent to the IP address and port number, wherein the heartbeat packet includes a negotiated and determined heartbeat session identifier.

[0042] The client can periodically send heartbeat packets to its stored IP address and port number at a preset heartbeat interval to detect whether the server is online. Similarly, the server can periodically send heartbeat packets to its stored IP address and port number at a preset heartbeat interval to detect whether the client is online. Optionally, the client and the server can add a heartbeat session ID to the heartbeat packet according to a negotiated rule or a preset rule, so that the other end can identify the heartbeat session ID from the received heartbeat packet.

[0043] Due to the existence of the dynamic allocation mechanism mentioned above, the following five scenarios may occur during the sending of heartbeat packets: Scenario 1 - the client or server has not been restarted after going offline from the IP address and port number, and the old IP address and port number are not occupied; Scenario 2 - the client or server has not been restarted after going offline from the IP address and port number, and the old IP address and port number are occupied by another client or server; Scenario 3 - the client or server is restarted after going offline from the IP address and port number, and after restarting, the new IP address and port number are used and the locally stored session information is cleared, and the old IP address and port number are not occupied; Scenario 4 - the client or server is restarted after going offline from the IP address and port number, and after restarting, the old IP address and port number are used and the locally stored session information is cleared; Scenario 5 - the client or server is restarted after going offline from the IP address and port number, and after restarting, the new IP address and port number are used and the locally stored session information is cleared, and the old IP address and port number are occupied by another client or server.

[0044] It should be noted that in the above-mentioned scenarios 2 and 5, the intended recipient of the heartbeat packet sender (i.e., the "opposite end" with which SOA communication is established in step S120) is different from the actual recipient of the heartbeat packet. In order to separate the two, the actual recipient of the heartbeat packet is referred to as the "receiver" in this article.

[0045] In step S150, the peer is determined to be offline in response to receiving a first response from the receiver of the heartbeat packet, wherein the first response indicates that the receiver cannot find information matching the heartbeat session identifier included in the heartbeat packet in its locally stored session information.

[0046] Step S150 is intended to quickly identify the above scenario 2, scenario 4 or scenario 5. For example, after receiving the heartbeat packet, the receiver can first identify the heartbeat session identifier from the received heartbeat packet according to the negotiated rules or preset rules, and then search the locally stored session information for information matching the heartbeat session identifier.

[0047] It is understandable that if the other end is always online, it has stored the heartbeat session identifier locally after the two parties negotiate to determine the heartbeat session identifier, so it can find information matching the heartbeat session identifier included in the heartbeat packet in the locally stored session information. On the contrary, in scenario 2, scenario 4 or scenario 5, that is, when the old IP address and port number are occupied by another client or service end or the locally stored session information has been cleared, the recipient will not be able to find information matching the heartbeat session identifier included in the heartbeat packet in its locally stored session information. At this time, the recipient will generate a first response and send it to the heartbeat packet sending subject to inform it that the expected receiving subject has gone offline. Accordingly, after receiving the first response, the sending subject determines that its expected receiving subject has gone offline.

[0048] It should be noted that even if the peer end quickly restarts within a heartbeat packet sending interval, since the local session information has been cleared in time after the restart, information matching the heartbeat session identifier included in the heartbeat packet cannot be found in the locally stored session information.

[0049] Furthermore, method 10 may also include an identification step for the above scenario 1 or scenario 3: when the heartbeat packet cannot be routed to the IP address and port number, it is determined that the peer end is offline.

[0050] In the above scenario 1 or scenario 3, the old IP address and port number are not occupied by any communication subject, so the heartbeat packet cannot be successfully routed to the IP address and port number. In a possible implementation, the client or server is configured with a network protocol stack, which can identify whether the heartbeat packet is routed to the target address. If it is not routed to the target address, an ICMP (Internet Control Message Protocol) message "Service Unreachable" is generated. In response to receiving the "Service Unreachable" message, the client or server can determine that the other party has gone offline.

[0051] Furthermore, in addition to the improved heartbeat detection mechanism, method 10 may also include other offline identification mechanisms as described below.

[0052] Optionally, method 10 further includes an active broadcast mechanism: the server sends a broadcast message after restarting to notify the client that the server has been offline and restarted. In a possible implementation, if the server and the client are in a local area network environment, the server can send the broadcast message to all devices in the local area network. In a possible implementation, the server can re-register with the service registration center after restarting, and the client can monitor these registration information to know that the server has restarted.

[0053] Optionally, method 10 further includes a business discovery mechanism. Specifically, in addition to the heartbeat session, the client and the server can also establish a business session. A business session refers to a connection established between a client and a server to implement business interaction (for example, sending a business request such as a data access request or a service call request, or returning a response to a business request). Similar to the heartbeat session, the client or the server can negotiate with the other end to determine the business session ID and store it locally to uniquely identify the business session established this time. Optionally, in order to save computing power, the negotiated heartbeat session ID can be reused as the business session ID. After establishing the business session, the client or the server sends a business request (for example, an API (Application Programming Interface) call request, a data access request, an identity authentication request, a time notification, etc.) to the IP address and port number stored in step S120 according to business needs, and includes the negotiated business session ID in the business request.

[0054] The offline determination principle in the service discovery mechanism is similar to the heartbeat detection mechanism, that is, the identification for scenarios 1-5 above can be applied by analogy to the service discovery mechanism. Specifically, the client or server may determine that the peer is offline when the service request cannot be routed to the stored IP address and port number. In addition, the client or server may determine that the peer is offline in response to receiving a second response from the recipient of the service request, wherein the second response indicates that the recipient cannot find information matching the service session ID included in the service request in its locally stored session information. Exemplarily, the second response is generated by the recipient in the following situations: the peer is offline and the IP address and port number are occupied by the recipient, and the recipient is not the peer; or the peer has cleared the locally stored session information after restarting, and continues to use the IP address and port number, wherein the recipient is the peer.

[0055] Furthermore, method 10 may also include recovery measures for scenarios 2, 4, and 5: deleting the locally stored session information related to the IP address and port number, and re-establishing a heartbeat session with the recipient to continue monitoring the online or offline status of the recipient. In a possible implementation, in response to receiving the above-mentioned first response or second response, deleting all sessions established for the IP address and port number; re-establishing a heartbeat session for the IP address and port number, storing a new heartbeat session identifier negotiated with the recipient; and periodically sending a heartbeat packet to the IP address and port number, wherein the heartbeat packet includes a new heartbeat session identifier.

[0056] According to one or more embodiments of the present application, the offline identification method 10 proposes an improved heartbeat detection mechanism, which aims to improve the real-time and accuracy of offline identification of SOA communication subjects by timely clearing local session information, negotiating a unique heartbeat session identifier, including the heartbeat session identifier in the heartbeat packet, and making offline determinations based on the heartbeat session identifier, thereby improving the security and stability of SOA communication. In addition, according to one or more embodiments of the present application, the offline identification method 10 integrates the heartbeat detection mechanism, the active broadcast mechanism, and the service discovery mechanism, further improving the flexibility of offline identification.

[0057] Continue to refer to Figure 2 , Figure 2 A schematic diagram of an SOA communication architecture according to one or more embodiments of the present application.

[0058] In the SOA communication architecture, a client can connect to multiple servers at the same time, and a server can connect to multiple clients at the same time. Figure 2 Only the case where one client (Client 1) is connected to two servers (Server 1 and Server 2) is shown.

[0059] The establishment of a session is described below using Client 1 and Server 1 as the communicating parties. The principle is similarly applicable to the establishment of a session between Client 1 and Server 2.

[0060] After both Client 1 and Server 1 have obtained the IP address and port number of the other end, Client 1 creates ServerContext(Server 1) locally to store the IP address, port number, and session information related to the IP address and port number of Server 1. Correspondingly, Server 1 creates ClientContext(Client 1) locally to store the IP address, port number, and session information related to the IP address and port number of Client 1.

[0061] Next, Client 1 establishes a heartbeat session (HB Session) with Server 1, negotiates to determine the heartbeat session ID and stores the heartbeat session ID in ServerContext (Server 1) and ClientContext (Client 1). Client 1 continues to establish a business session (C1_S1 Session) with Server 1, negotiates to determine the business session ID and stores the business session ID in ServerContext (Server 1) and ClientContext (Client 1).

[0062] like Figure 2 Any of the Client 1, Server 1 and Server 2 shown in the figure can be used as the execution subject of the method 10 shown in Figure 1 to implement offline determination for its counterpart.

[0063] Figure 3 3 is a schematic block diagram of an electronic device 30 according to one or more embodiments of the present application. The electronic device 30 includes a memory 310, a processor 320, and a computer program 330 stored in the memory 310 and executable on the processor 320. The execution of the computer program 330 enables the following Figure 1 The offline identification method 10 shown is executed. Exemplarily, the electronic device 30 may be an ECU, a domain controller, a CPU, or a module such as an in-vehicle infotainment system, a driving assistance system, etc. that needs to communicate with other systems, or a vehicle.

[0064] In addition, the present application can also be implemented as a computer storage medium, in which is stored a program for causing a computer to execute the following steps: Figure 1Here, as the computer storage medium, various computer storage media such as disks (e.g., magnetic disks, optical disks, etc.), cards (e.g., memory cards, optical cards, etc.), semiconductor memories (e.g., ROMs, nonvolatile memories, etc.), and tapes (e.g., magnetic tapes, cassette tapes, etc.) can be used.

[0065] In the applicable situation, hardware, software or a combination of hardware and software can be used to realize the various embodiments provided by the application. Moreover, in the applicable situation, without departing from the scope of the application, the various hardware components and / or software components set forth herein can be combined into a composite component comprising software, hardware and / or both. In the applicable situation, without departing from the scope of the application, the various hardware components and / or software components set forth herein can be divided into subcomponents comprising software, hardware or both. In addition, in the applicable situation, it is contemplated that the software component can be implemented as a hardware component, and vice versa.

[0066] Software (such as program code and / or data) according to the present application can be stored on one or more computer storage media. It is also contemplated that the software identified herein can be implemented using one or more general or special-purpose computers and / or computer systems, networked and / or otherwise. Where applicable, the order of the various steps described herein can be changed, combined into composite steps, and / or divided into sub-steps to provide the features described herein.

[0067] The embodiments and examples set forth herein are provided to best illustrate embodiments according to the present application and its specific applications, and thereby enable those skilled in the art to implement and use the present application. However, those skilled in the art will appreciate that the above description and examples are provided only for ease of illustration and example. The description set forth is not intended to cover all aspects of the present application or to limit the present application to the precise form disclosed.

Claims

1. A method for offline identification based on SOA communication, characterized in that: The method is performed by a client or a server, and includes the following steps: In response to going online or restarting, clearing locally stored session information; Store the IP address and port number of the peer with which SOA communication is currently established; Establishing a heartbeat session for the IP address and port number, and storing a heartbeat session identifier determined by negotiation with the peer end, wherein the heartbeat session identifier is used to uniquely identify the heartbeat session established this time; Periodically sending a heartbeat packet to the IP address and port number, wherein the heartbeat packet includes the negotiated and determined heartbeat session identifier; and The peer end is determined to be offline in response to receiving a first response from a receiver of the heartbeat packet, wherein the first response indicates that the receiver cannot find information matching the heartbeat session identifier included in the heartbeat packet in its locally stored session information.

2. The offline identification method according to claim 1, characterized in that: The first response is generated by the recipient in the following situations: The peer end has gone offline and the IP address and port number are occupied by the receiver, which is not the peer end.

3. The offline identification method according to claim 1, characterized in that: The first response is generated by the recipient in the following situations: The peer end has cleared the locally stored session information after restarting, and continues to use the IP address and port number, wherein the recipient is the peer end.

4. The offline identification method according to claim 1, characterized in that: The heartbeat session identifier is generated by the client and sent to the server.

5. The offline identification method according to claim 1, characterized in that: The method further comprises: When the heartbeat packet cannot be routed to the IP address and port number, it is determined that the peer end is offline.

6. The offline identification method according to claim 1, characterized in that: The method further comprises: In response to establishing an SOA communication connection with the peer, the context of the peer is stored locally, the context of the peer includes the IP address, port number and session information related to the IP address and port number of the peer, wherein the session information includes the heartbeat session identifier.

7. The offline identification method according to claim 1, characterized in that: The method further comprises: In response to receiving the first response, deleting all sessions established for the IP address and port number; Re-establishing a heartbeat session for the IP address and port number, and storing a new heartbeat session identifier determined through negotiation with the recipient; and Periodically sending a heartbeat packet to the IP address and port number, wherein the heartbeat packet includes the new heartbeat session identifier.

8. An electronic device, characterized in that: The invention comprises: a memory; a processor; and a computer program stored in the memory and executable on the processor, wherein the execution of the computer program enables the offline identification method according to any one of claims 1 to 7 to be executed.

9. The electronic device according to claim 8, characterized in that: The electronic device is a vehicle.

Images