Service discovery method, apparatus and electronic device

Abstract

The application provides a service discovery method and device and electronic equipment, relates to the technical field of communication, and comprises the following steps: receiving a service subscription event sent by a client, wherein the service subscription event comprises access information of the client and subscribed service information; querying, according to the subscribed service information, a service end matched with the service subscription event on an in-vehicle node and access information of the service end; judging, according to the access information of the service end and the access information of the client, whether the service end is located on an internal element of the in-vehicle node and whether the client is located on an in-vehicle node corresponding to the service end; and pushing the access information of the service end to the client after distinguishing between external use and local use of the access information according to a judgment result. Therefore, the access information of the service end can be distinguished between external use and local use, and the access information of the service end suitable for use can be pushed according to the distinguished result, so that connection failure of the client and the service end can be avoided and service discovery success can be ensured.

Description

Technical Field

[0001] This application relates to the field of communication technology, and in particular to a service discovery method, apparatus and electronic device. Background Technology

[0002] As automotive electronic (EE) system architecture has evolved from traditional point-to-point connections to distributed architectures, Service-Oriented Architecture (SOA) has become the most important development methodology, with service discovery systems supporting SOA forming the infrastructure. To meet SOA requirements, communication protocols based on service discovery between in-vehicle nodes enable dynamic deployment of communication endpoints. Before establishing a connection between the client and server, the client is unaware of the server's access information. Typically, through service discovery communication protocols, access information for the server corresponding to a specific service is pushed to clients subscribed to that service, and the client then uses this access information to communicate with the server.

[0003] Currently, service discovery methods involve directly pushing the retrieved server access information to the client. However, a single in-vehicle node contains multiple internal components, such as chips. If the server resides on one of these internal components, directly pushing the retrieved server access information to the client could prevent the client from connecting to the server, leading to service discovery failure. Summary of the Invention

[0004] This application provides a service discovery method, apparatus, and electronic device, which can distinguish between external and local access information of the server and push the appropriate access information of the server according to the distinction, thereby avoiding client and server connection failures and ensuring successful service discovery.

[0005] Firstly, a service discovery method is provided, including:

[0006] Receive service subscription events sent by the client. The service subscription event contains the client's access information and the subscribed service information.

[0007] Based on the service information, query the server that matches the service subscription event on the in-vehicle node, as well as the server's access information;

[0008] Based on the access information from the server and the client, determine whether the server is located on an internal component of the in-vehicle node, and whether the client is located on an in-vehicle node.

[0009] Based on the judgment results, the access information of the server is processed to distinguish between external use and local use before being pushed to the client, so that the client can communicate with the server based on the differentiated access information.

[0010] Secondly, a service discovery device is provided, comprising:

[0011] The receiving module is used to receive service subscription events sent by the client. The service subscription event contains the client's access information and the subscribed service information.

[0012] The query module is used to query the server on the in-vehicle node that matches the service subscription event, as well as the server's access information, based on the service information.

[0013] The judgment module is used to determine whether the server is located on an internal component of an in-vehicle node and whether the client is located on the in-vehicle node where the server is located, based on the access information from the server and the access information from the client.

[0014] The processing module is used to differentiate between external and local use of the server's access information based on the judgment result, and then push the information to the client so that the client can communicate with the server based on the differentiated access information.

[0015] Thirdly, an electronic device is provided, comprising:

[0016] The processor and memory, the memory being used to store computer programs, and the processor being used to call and run the computer programs stored in the memory to perform methods as described in the various implementations of the first aspect.

[0017] Fourthly, a computer-readable storage medium is provided for storing a computer program that causes a computer to perform the methods described in the implementations of the first aspect.

[0018] The technical solution provided in this application offers a service discovery method, apparatus, and electronic device. When a client needs to use a service, it receives a service subscription event sent by the client. This service subscription event includes the client's access information and subscribed service information. Simultaneously, based on the subscribed service information, it queries the server on the in-vehicle node that matches the service subscription event and its access information. Based on the server's and client's access information, it determines whether the server is located on an internal component of the in-vehicle node and whether the client is located on the corresponding in-vehicle node. Based on the determination result, it distinguishes between external and local use of the server's access information and pushes it to the client, enabling the client to communicate with the server based on the differentiated access information. Therefore, the technical solution of this application can distinguish between external and local use of server access information and push appropriate access information based on this distinction. This avoids situations where clients on external in-vehicle nodes cannot establish a connection with servers on internal components of in-vehicle nodes, ensuring successful service discovery and guaranteeing successful client access to the server or successful invocation of the corresponding service.

[0019] It should be understood that the above general description and the following detailed description are exemplary and explanatory only, and are not intended to limit this application. Other features and advantages of this application will be described in detail in the subsequent detailed description section. Attached Figure Description

[0020] To more clearly illustrate the technical solutions in the embodiments of this application, the accompanying drawings used in the description of the embodiments will be briefly introduced below. Obviously, the accompanying drawings described below are only some embodiments of this application. For those skilled in the art, other drawings can be obtained based on these drawings without creative effort.

[0021] Figure 1 A flowchart illustrating a service discovery method provided in an embodiment of this application;

[0022] Figure 2 A schematic diagram of an in-vehicle node provided in an embodiment of this application;

[0023] Figure 3 A flowchart illustrating a service discovery method provided in another embodiment of this application;

[0024] Figure 4 A schematic diagram of the structure of a service discovery device provided in an embodiment of this application;

[0025] Figure 5 This is a schematic diagram of the structure of an electronic device provided in an embodiment of this application. Detailed Implementation

[0026] The technical solutions of the embodiments of this application will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some embodiments of this application, and not all embodiments. Based on the embodiments of this application, all other embodiments obtained by those of ordinary skill in the art without creative effort are within the scope of protection of this application.

[0027] It should be noted that the terms "first," "second," etc., in the specification, claims, and accompanying drawings of this application are used to distinguish similar objects and are not necessarily used to describe a specific order or sequence. It should be understood that such data can be interchanged where appropriate so that the embodiments of this application described herein can be implemented in orders other than those illustrated or described herein. Furthermore, the terms "comprising" and "having," and any variations thereof, are intended to cover non-exclusive inclusion; for example, a process, method, system, product, or server that comprises a series of steps or units is not necessarily limited to those steps or units explicitly listed, but may include other steps or units not explicitly listed or inherent to such processes, methods, products, or devices.

[0028] As EE system architecture has evolved from traditional point-to-point connections to distributed architectures, SOA has become the most important development methodology, with service discovery systems supporting SOA becoming essential infrastructure. To meet SOA requirements, communication between in-vehicle nodes is based on service discovery protocols, enabling dynamic deployment at both ends of the communication. Before establishing a connection between the client and server, the client is unaware of the server's access information. Typically, through service discovery communication protocols, the access information of the server providing the corresponding service is pushed to clients subscribed to that service, and then the client uses this access information to communicate with the server.

[0029] Currently, communication between nodes within a vehicle uses Ethernet, mostly employing Layer 2 networks, with routing and upper-layer strategies rarely used. As computing power demands increase, a single in-vehicle node contains multiple components. Furthermore, due to differences in component solutions from various suppliers, to enable communication between these components, OEMs often assign an external access message to each in-vehicle node and internal access messages to each individual component. That is, in-vehicle nodes communicate with each other via external access messages, while components within the same node communicate with each other via internal access messages. However, if a server on one of the internal components of an in-vehicle node queries for internal access information, and a client subscribing to the service on another in-vehicle node directly pushes the server's internal access information to the client, it will prevent the client from connecting to the server, resulting in service discovery failure.

[0030] Therefore, in order to ensure successful service discovery, this application provides a service discovery method, apparatus, and electronic device.

[0031] The technical solution of this application will be described in detail below:

[0032] Figure 1 The flowchart illustrates a service discovery method provided in this application embodiment. This method is applied to the central node of a service discovery system, specifically the central node of a Scalable Service-Oriented Middleware over IP (SOME / IP) network. The method can also be applied to in-vehicle nodes or network devices, but is not limited to these. Figure 1 As shown, the method may include the following steps:

[0033] Step 110: Receive the service subscription event sent by the client. The service subscription event contains the client's access information and the subscribed service information.

[0034] In this embodiment, when a client needs to invoke or use a service, the client sends a service subscription event to the central node to obtain information related to the service. The central node then receives the service subscription event sent by the client. The client can be referred to as the service user. The client's access information may include the client's name, network address, and port number. The network address can be an IP address, and the client can be accessed through this access information. The subscribed service information may include the service name, service version number, service publication period, service validity period (Time-To-Live, TTL), serial port, and other possible parameters.

[0035] Step 120: Based on the subscribed service information, query the server on the in-vehicle node that matches the service subscription event and the server's access information.

[0036] In a specific embodiment, step 120, "based on the subscribed service information, querying the server and its access information on the in-vehicle node that match the service subscription event," may include: querying a preset service registry based on the subscribed service information to determine the server and its access information on the in-vehicle node that match the service subscription event. The preset service registry stores access and service information corresponding to different servers. Different servers can pre-register with the central node. A server can be a service provider; the client and server are relative. When a service needs to be called or used, it is called a client; when a service is provided, it is called a server. The server's access information includes the client's name, network address, and port number, etc. The network address can be an IP address. The server and its corresponding service can be accessed through the server's access information.

[0037] Specifically, the default service registry records available services and their server names, IP addresses, port numbers, etc. When a client needs to call or use a service, it sends a service subscription event to the central node. The central node matches the service information in the default service registry with the service information that matches the subscription information, and identifies the server corresponding to the matching service information as the server providing the subscription service, and determines the server's network address, port number, and other access information. In other words, after receiving a service use request event from a client, the central node searches the default service registry for services that match the service subscription event and finds the corresponding server. If a matching service is found, the central node obtains the server's name and IP address.

[0038] In a specific embodiment, the central node can also receive service registration request events sent by different servers. Each service registration request event sent by a server includes the server's access information and the service information to be registered by the server. Associations are established between the identification information of different servers and the service information to be registered by different servers, and the obtained relationship information is saved in a preset service registry. By having different servers register their service information with the central node, the central node can be responsible for maintaining the identification and service information of different servers, thereby maintaining the service information provided by different servers.

[0039] Step 130: Based on the access information from the server and the client, determine whether the server is located on an internal component of the in-vehicle node, and whether the client is located on the in-vehicle node where the server is located.

[0040] In a specific embodiment, step 130, "determining whether the server is located on an internal component of an in-vehicle node and whether the client is located on the in-vehicle node where the server is located, based on the server's access information and the client's access information," can be performed as follows: Obtain the in-vehicle network topology map; based on the server's access information, the client's access information, and the in-vehicle network topology map, determine whether the server is located on an internal component of an in-vehicle node and whether the client is located on the in-vehicle node where the server is located. Specifically, the in-vehicle network topology map records all in-vehicle nodes or all components, as well as the access information corresponding to each in-vehicle node and component.

[0041] In this embodiment, a single in-vehicle node contains multiple components. Due to differences in component solutions from various suppliers, to enable communication between these components, the OEM can use NAT (Network Address Translation) and NAPT (Network Address Port Translation) technologies. This involves assigning external access information to each component on the network device and internal access information for internal use. In other words, in-vehicle nodes communicate with each other using external access information, while components within the same in-vehicle node communicate with each other using internal access information. For a single component, communication within the same in-vehicle node is possible via internal access information, while components in external in-vehicle nodes can only be accessed through the external network access information of the in-vehicle node to which the component resides.

[0042] In this embodiment of the application, to better illustrate the technical solution, the following is provided: Figure 2 ,like Figure 2 As shown, the server can reside on an internal component of a vehicle node or outside of an internal component of a vehicle node. The client and server can reside on the same vehicle node, on the same internal component of the same vehicle node, or on different internal components of the same vehicle node. Within the same vehicle node, the client and server can be on different internal components; one can reside on an internal component and the other outside, or both can reside outside. The client and server can also reside on different vehicle nodes. Different location relationships between the client and server result in different access paths. If the location relationship between the client and server is not considered, and a fixed method is used to relay server access information to the client, it may lead to a connection failure between the server and the client.

[0043] In this embodiment, by determining whether the server is located on an internal component of an in-vehicle node and whether the client is located on the in-vehicle node where the server is located, based on the access information of the server and the access information of the client, the location of the client and the server and the relationship between their in-vehicle nodes can be determined. This enables the server's access information to be processed differently based on their location and the relationship between their in-vehicle nodes, thereby extending the service protocol and solving the service discovery failure problem caused by the service discovery method of "directly pushing the access information found to the client".

[0044] Step 140: Based on the judgment result, the access information of the server is processed to distinguish between external use and local use, and then pushed to the client so that the client can communicate with the server based on the processed access information.

[0045] In this embodiment, if the server and client are not on the same in-vehicle node, the server's access information is considered to be for external use, meaning communication between the client and server occurs outside the network environment. If the server and client are on the same in-vehicle node, the server's access information is considered to be for local use, meaning communication between the client and server occurs within the network environment. If the server and client are not on the same in-vehicle node, pushing the server's local intranet access information to the client for connection will fail. The step of "differentiating between external and local use of the server's access information" can include: distinguishing whether the server's access information is for external or local use; and then processing the server's access information based on the distinction result. This processing includes converting the server's access information and maintaining the server's access information unchanged. Specifically, if the server's access information is for external use and is located on an internal component of the in-vehicle node, the server's access information is converted. If the server's access information is for local use, the server's access information is maintained unchanged. By distinguishing between external and local use of server access information, we can avoid pushing access information used locally by the server to the client for connection.

[0046] In summary, the technical solution provided in this application receives a service subscription event sent by the client when the client needs to use the service. This service subscription event includes the client's access information and the subscribed service information. Simultaneously, based on the subscribed service information, the system queries the server matching the service subscription event and its access information. Based on the server's and client's access information, it determines whether the server is located on an internal component of the in-vehicle node and whether the client is located on the corresponding in-vehicle node. Based on the determination result, the system distinguishes between external and local use of the server's access information before pushing it to the client, enabling the client to communicate with the server based on the differentiated access information. Therefore, the technical solution of this application can distinguish between external and local use of the server's access information and push appropriate access information based on this distinction. This avoids situations where clients on external in-vehicle nodes cannot establish a connection with the server on the internal component of the in-vehicle node, ensuring successful service discovery and successful client access to the server or successful invocation of the server's corresponding service.

[0047] based on Figure 1 The embodiments shown are refinements and extensions of the above embodiments. To fully illustrate the specific implementation process of the method in this embodiment, this embodiment provides the following: Figure 3 The specific method is shown. For example... Figure 3 As shown, the method includes the following steps:

[0048] Step 210: Receive the service subscription event sent by the client. The service subscription event contains the client's access information and the subscribed service information.

[0049] Step 220: Based on the subscribed service information, query the server that matches the in-vehicle node with the service subscription event and the server's access information.

[0050] Step 230: Based on the access information from the server and the client, determine whether the server is located on an internal component of the in-vehicle node, and whether the client is located on the in-vehicle node where the server is located.

[0051] In a specific embodiment, step 230, "determining whether the server is located on an internal component of the in-vehicle node and whether the client is located on the in-vehicle node where the server is located, based on the server's access information and the client's access information," may specifically include: comparing the server's access information with the in-vehicle node's external network access information to determine whether the server is located on an internal component of the in-vehicle node; and comparing the client's access information with the in-vehicle node's external access information to determine whether the client is located on the in-vehicle node.

[0052] It should be noted that if the server's access information on the in-vehicle node differs from the in-vehicle node's external network access information, it indicates that the server's access information is internal network access information, and the server is located on an internal component of the in-vehicle node. If the server's access information on the in-vehicle node is the same as the in-vehicle node's external network access information, it indicates that the server's access information is external network access information, and the server is located outside the internal component of the in-vehicle node. If the client's access information differs from the in-vehicle node's external network access information, it indicates that the client is not located on the in-vehicle node. Conversely, if the client's access information is the same as the in-vehicle node's external network access information, it indicates that the client is located on the in-vehicle node. Furthermore, based on the server's access information, the client's access information, and the in-vehicle network topology diagram, it can be determined whether the server is located on an internal component of the in-vehicle node, and whether the client is located on the in-vehicle node where the server resides. The in-vehicle network topology diagram records all in-vehicle nodes or all components, as well as the access information corresponding to each in-vehicle node and component.

[0053] Step 240: If the determination result is that the server is located on an internal component of the in-vehicle node and the client is not located on the in-vehicle node where the server is located, then based on the preset conversion mapping rules, the server's access information is converted into the in-vehicle node's external network access information and pushed to the client so that the client can communicate with the server based on the in-vehicle node's external network access information.

[0054] In the embodiments of this application, if the determination result is that the server is located on an internal component of an in-vehicle node, and the client is not located on the same in-vehicle node as the server, it indicates that the server and the client are not on the same in-vehicle node. Therefore, the server's access information is considered to be for external use, meaning it belongs to communication between a client outside the network environment and the server, and is located on an internal component of an in-vehicle node. In this case, the server's access information is converted. By distinguishing between external and local use of the server's access information, it is possible to avoid pushing access information used locally by the server to the client for connection. The preset conversion mapping rules can be stored in a configuration file, specifically configured through a service instance. Specifically, the conversion mapping can be configured through the "gateway" field. In a NAT network environment, access information conversion can be performed through a NAT gateway. In a non-NAT network environment, the configuration for external and local use of the server's access information is the same. Specifically, conversion can be performed for access information under TCP (Transmission Control Protocol) / UDP (User Datagram Protocol).

[0055] In a specific embodiment, the preset conversion mapping rule is a preset network address translation rule. The step "based on the preset conversion mapping rule, converting the server's access information into the vehicle node's external network access information and pushing it to the client, so that the client can communicate with the server based on the vehicle node's external network access information" can specifically include: if the server's access information is the server's network address information, then based on the preset network address translation rule, mapping the server's network address information into the vehicle node's external network address information. Specifically, the preset network address translation rule can be a preset IP address translation rule. If the server's access information is the server's internal network IP address information, then based on the preset IP address translation rule, mapping the server's internal network IP address information into the vehicle node's external network IP address information. The internal network IP address information and the internal network IP address information are from different network segments. For example, if the server's internal IP address is 172.30.30.30.1 to 172.30.30.30.255, then the converted external IP address can be: 192.168.10.1 to 192.168.10.255 (TCP); 192.168.10.1 to 192.168.10.255:30501 ( / UDP).

[0056] In a specific embodiment, the preset conversion mapping rule is a preset network address port conversion rule. The step "based on the preset conversion mapping rule, converting the server's access information into the vehicle node's external network access information and pushing it to the client, so that the client can communicate with the server based on the vehicle node's external network access information" can specifically include: if the server's access information is the server's network address and port information, then based on the preset network address and port conversion rule, mapping the server's network address and port information into the vehicle node's external network address and port information. Specifically, the preset network address conversion rule can be a preset IP address and port conversion rule; if the server's access information is the server's internal network IP address and port information, then based on the preset IP address and port conversion rule, mapping the server's internal network IP address and port information into the vehicle node's external network IP address and port information.

[0057] In a specific embodiment, the IP address and IP address port number can be converted using the `option` field in the server's service subscription response message and service call request response message, according to the aforementioned preset conversion mapping rules. Specifically, the server's IP address can be passed using the `SERVER_IP` option of the `option` field, and the server's IP address port number can be passed using the `SERVER_PORT` option of the `option` field.

[0058] Step 250: If the determination result is that the server is located on an internal component of the in-vehicle node and the client is located on the in-vehicle node where the server is located, then the server's access information is pushed to the client so that the client can communicate with the server based on the server's access information.

[0059] In this embodiment, if the determination result is that the server is located on an internal component of a node within the vehicle, and the client is located on the same node, then the server's access information is considered to be for local use, meaning it pertains to communication between the client and server within the network environment. If the server's local intranet access information is pushed to the client for connection, the connection will succeed. In this case, the server's access information remains unchanged, and it is pushed to the client so that the client can communicate with the server based on this information. By distinguishing between external and local use of the server's access information, the resource consumption for processing access information can be saved while ensuring a successful connection between the server and the local client.

[0060] Step 260: If the determination result is that the server is located outside the internal components of the in-vehicle node, then the server's access information is pushed to the client so that the client can communicate with the server based on the server's access information.

[0061] In this embodiment, if the determination result indicates that the server is located in an in-vehicle node but outside the internal components, it means that the server's access information is the external network access information of the in-vehicle node. Even though the client and server are not on the same in-vehicle node, they can still successfully connect to the server through the client's external network access information from the in-vehicle node. In this case, the server's access information is kept unchanged and pushed to the client so that the client can communicate with the server based on this access information. By distinguishing between external and local use of the server's access information, the resource consumption for processing access information can be saved while ensuring a successful connection between the server and the local client.

[0062] It should be noted that the client can use the SOME / IP protocol to call or use relevant services on the server. The communication process with the server can specifically include: after the client establishes a SOME / IP communication connection with the server, the server encapsulates the data packet to be transmitted at the application layer, performs message encapsulation based on the SOME / IP protocol, and then sends it to the underlying protocol stack; after receiving the message-encapsulated data packet, the underlying protocol stack encapsulates it again and transmits it to the network transmission bus; the network transmission bus transmits the received data packet to the network transmission bus connected to the service user based on the transmission channel, and then transmits it to the underlying protocol stack of the target client; after the client's underlying protocol stack unpacks the packet, it parses it based on the SOME / IP message format, and then obtains the transmission data of the corresponding service.

[0063] In a specific embodiment, service discovery can also be performed through a gateway. The communication process between the client and the server can further include: after the client establishes a SOME / IP communication connection with the service provider, the server encapsulates the data packet to be transmitted at the application layer, then encapsulates it again based on the SOME / IP protocol before sending it to the underlying protocol stack; the underlying protocol stack receives the encapsulated data packet, encapsulates it again, and transmits it to the network transmission bus; the network transmission bus transmits the re-encapsulated data packet to the gateway; the gateway, based on the transmission channel selected according to priority, transmits the received data packet to the network transmission bus connected to the client, and then transmits it to the client's underlying protocol stack; the client's underlying protocol stack unpacks the packet, parses it based on the SOME / IP message format, and then obtains the transmission data of the corresponding service. When the server uses the SOME / IP protocol to call the relevant service process in the service provider, the client and server can communicate and interact directly without the participation or intervention of a central node, and there is no need for a central node to perform message encapsulation or forwarding based on the SOME / IP protocol.

[0064] It should be noted that during communication between the client and server, data can be serialized based on the data serialization format defined by the SOME / IP protocol. The serialized data is then transmitted over the network to ensure correct parsing and understanding between different nodes. Similarly, the client and server deserialize data based on the data deserialization format defined by the SOME / IP protocol. Furthermore, the SOME / IP protocol supports different communication modes, such as request-response and publish-subscribe patterns. The client and server can choose the appropriate communication mode based on service requirements.

[0065] In this embodiment, during communication between the client and server, network errors, data errors, and other issues may occur. The client-server communication process can be handled based on the error handling mechanism of the SOME / IP protocol, including error detection and retry strategies, such as retransmitting data or disconnecting the connection, to ensure communication stability and reliability. When communication between the client and server ends, the connection can be closed and related resources released via the SOME / IP protocol. This includes closing sockets and releasing memory to ensure normal system operation and efficient resource utilization.

[0066] In summary, the technical solution provided in this application receives a service subscription event sent by the client when the client needs to use the service. This service subscription event includes the client's access information and the subscribed service information. Simultaneously, based on the subscribed service information, the system queries the server matching the service subscription event and its access information. Based on the server's and client's access information, it determines whether the server is located on an internal component of the in-vehicle node and whether the client is located on the corresponding in-vehicle node. Based on the determination result, the system distinguishes between external and local use of the server's access information before pushing it to the client, enabling the client to communicate with the server based on the differentiated access information. Therefore, the technical solution of this application can distinguish between external and local use of the server's access information and push appropriate access information based on this distinction. This avoids situations where clients on external in-vehicle nodes cannot establish a connection with the server on the internal component of the in-vehicle node, ensuring successful service discovery and successful client access to the server or successful invocation of the server's corresponding service. Furthermore, it saves resources consumed in processing access information while ensuring a successful connection between the server and client.

[0067] Based on the above Figure 1 , Figure 3 A detailed description of the provided service discovery methods, such as Figure 4 As shown, Figure 4 This is a block diagram illustrating a service discovery apparatus according to an exemplary embodiment. The apparatus is applied to the central node of a service discovery system, specifically a SOME / IP central node. The method can also be applied to in-vehicle nodes or network devices, but is not limited thereto. Figure 4 As shown, the device includes:

[0068] The receiving module 31 can be used to receive service subscription events sent by the client. The service subscription event includes the client's access information and the subscribed service information.

[0069] The query module 32 can be used to query the server that matches the service subscription event and the server's access information based on the service information.

[0070] The judgment module 33 can be used to determine whether the server is located on the internal component of the in-vehicle node and whether the client is located on the in-vehicle node based on the access information of the server and the access information of the client.

[0071] The processing module 34 can be used to distinguish between external and local use of the access information of the server based on the judgment result and then push it to the client so that the client can communicate with the server based on the distinguished access information.

[0072] In some embodiments of this application, the processing module 34 can be used to convert the server's access information into the vehicle's external network access information based on a preset conversion mapping rule and push it to the client if the determination result is that the server is located on the internal component of the in-vehicle node and the client is not located on the in-vehicle node, so that the client can communicate with the server based on the external network access information of the in-vehicle node.

[0073] In some embodiments of this application, the processing module 34 can be used to push the access information of the server to the client if the determination result is that the server is located on the internal component of the in-vehicle node and the client is located on the in-vehicle node, so that the client can communicate with the server based on the access information of the server.

[0074] In some embodiments of this application, the processing module 34 can be used to push the access information of the server to the client if the determination result is that the server is located outside the internal components of the in-vehicle node, so that the client can communicate with the server based on the access information of the server.

[0075] In some embodiments of this application, the preset conversion mapping rules include preset network address conversion rules. The processing module 34 can be used to map the network address information of the server to the external network address information of the in-vehicle node based on the preset network address conversion rules if the access information of the server is the network address information of the server.

[0076] In some embodiments of this application, the preset conversion mapping rules include preset network address port conversion rules. The processing module 34 can be used to map the network address port information of the server to the external network address port information of the in-vehicle node based on the preset network address port conversion rules if the access information of the server is the network address port information of the server.

[0077] In some embodiments of this application, the determination module 33 can be used to compare the access information of the server with the external network access information of the in-vehicle node to determine whether the server is located on the internal component of the in-vehicle node; and to compare the access information of the client with the external access information of the in-vehicle node to determine whether the client is located on the in-vehicle node.

[0078] In summary, the technical solution provided in this application receives a service subscription event sent by the client when the client needs to use the service. This service subscription event includes the client's access information and the subscribed service information. Simultaneously, based on the subscribed service information, the system queries the server matching the service subscription event and its access information. Based on the server's and client's access information, it determines whether the server is located on an internal component of the in-vehicle node and whether the client is located on the corresponding in-vehicle node. Based on the determination result, the system distinguishes between external and local use of the server's access information before pushing it to the client, enabling the client to communicate with the server based on the differentiated access information. Therefore, the technical solution of this application can distinguish between external and local use of the server's access information and push appropriate access information based on this distinction. This avoids situations where clients on external in-vehicle nodes cannot establish a connection with the server on the internal component of the in-vehicle node, ensuring successful service discovery and successful client access to the server or successful invocation of the server's corresponding service.

[0079] Regarding the apparatus in the above embodiments, the specific manner in which each module performs its operation has been described in detail in the embodiments related to the method, and will not be elaborated upon here.

[0080] The service discovery apparatus of this application embodiment has been described above from the perspective of functional modules in conjunction with the accompanying drawings. It should be understood that this functional module can be implemented in hardware, in software instructions, or in a combination of hardware and software modules. Specifically, each step of the service discovery method embodiment in this application can be completed by integrated logic circuits in the processor's hardware and / or by software instructions. The steps of the service discovery method applied in this application embodiment can be directly manifested as execution by a hardware decoding processor, or by a combination of hardware and software modules in the decoding processor. Optionally, the software module can be located in a mature storage medium in the art, such as random access memory, flash memory, read-only memory, programmable read-only memory, electrically erasable programmable memory, registers, etc. This storage medium is located in memory, and the processor reads information from the memory and, in conjunction with its hardware, completes the steps of the above-described service discovery method embodiment.

[0081] Figure 5 This is a schematic block diagram of an electronic device 600 according to an embodiment of this application.

[0082] like Figure 5 As shown, the electronic device 600 may include:

[0083] The system includes a memory 610 and a processor 620. The memory 610 stores computer programs and transfers the program code to the processor 620. In other words, the processor 620 can retrieve and run the computer program from the memory 610 to implement the methods described in the embodiments of this application.

[0084] For example, the processor 620 can be used to execute the above-described method embodiments according to instructions in the computer program.

[0085] In some embodiments of this application, the processor 620 may include, but is not limited to:

[0086] General-purpose processors, digital signal processors (DSPs), application-specific integrated circuits (ASICs), field-programmable gate arrays (FPGAs), or other programmable logic devices, discrete gate or transistor logic devices, discrete hardware components, etc.

[0087] In some embodiments of this application, the memory 610 includes, but is not limited to:

[0088] Volatile memory and / or non-volatile memory. Non-volatile memory can be read-only memory (ROM), programmable read-only memory (PROM), erasable programmable read-only memory (EPROM), electrically erasable programmable read-only memory (EEPROM), or flash memory. Volatile memory can be random access memory (RAM), which is used as an external cache. By way of example, but not limitation, many forms of RAM are available, such as Static RAM (SRAM), Dynamic RAM (DRAM), Synchronous DRAM (SDRAM), Double Data Rate SDRAM (DDR SDRAM), Enhanced Synchronous DRAM (ESDRAM), Synchronous Link DRAM (SLDRAM), and Direct Rambus RAM (DR RAM).

[0089] In some embodiments of this application, the computer program may be divided into one or more modules, which are stored in the memory 610 and executed by the processor 620 to perform the method provided in this application. The one or more modules may be a series of computer program instruction segments capable of performing a specific function, which describe the execution process of the computer program in the controller.

[0090] like Figure 5 As shown, the electronic device 600 may further include:

[0091] Transceiver 630, which can be connected to processor 620 or memory 610.

[0092] The processor 620 can control the transceiver 630 to communicate with other devices; specifically, it can send data to or receive data from other devices. The transceiver 630 may include a transmitter and a receiver. The transceiver 630 may further include antennas, and the number of antennas may be one or more.

[0093] It should be understood that the various components in the electronic device are connected through a bus system, which includes a data bus, a power bus, a control bus, and a status signal bus.

[0094] This application also provides a computer storage medium storing a computer program thereon, which, when executed by a computer, enables the computer to perform the methods of the above-described method embodiments. Alternatively, one embodiment of this application also provides a computer program product containing instructions that, when executed by a computer, cause the computer to perform the methods of the above-described method embodiments.

[0095] When implemented using software, it can be implemented entirely or partially as a computer program product. This computer program product includes one or more computer instructions. When these computer program instructions are loaded and executed on a computer, all or part of the processes or functions described in the embodiments of this application are generated. The computer can be a general-purpose computer, a special-purpose computer, a computer network, or other programmable device. The computer instructions can be stored in a computer-readable storage medium or transmitted from one computer-readable storage medium to another. For example, the computer instructions can be transmitted from one website, computer, server, or data center to another via wired (e.g., coaxial cable, fiber optic, Digital Subscriber Line (DSL)) or wireless (e.g., infrared, wireless, microwave, etc.) means. The computer-readable storage medium can be any available medium accessible to a computer or a data storage device such as a server or data center that integrates one or more available media. The available medium can be a magnetic medium (e.g., floppy disk, hard disk, magnetic tape), an optical medium (e.g., Digital Video Disc (DVD)), or a semiconductor medium (e.g., Solid State Disk (SSD)).

[0096] Those skilled in the art will recognize that the modules and algorithm steps of the various examples described in conjunction with the embodiments claimed herein can be implemented in electronic hardware, or a combination of computer software and electronic hardware. Whether these functions are implemented in hardware or software depends on the specific application and design constraints of the technical solution. Those skilled in the art can use different methods to implement the described functions for each specific application, but such implementation should not be considered beyond the scope of this application.

[0097] In the several embodiments provided in this application, it should be understood that the disclosed systems, apparatuses, and methods can be implemented in other ways. For example, the apparatus embodiments described above are merely illustrative; for instance, the division of modules is only a logical functional division, and in actual implementation, there may be other division methods. For example, multiple modules or components may be combined or integrated into another system, or some features may be ignored or not executed. Furthermore, the coupling or direct coupling or communication connection shown or discussed may be through some interfaces; the indirect coupling or communication connection between apparatuses or modules may be electrical, mechanical, or other forms.

[0098] The modules described as separate components may or may not be physically separate. The components shown as modules may or may not be physical modules; that is, they may be located in one place or distributed across multiple network units. Some or all of the modules can be selected to achieve the purpose of this embodiment according to actual needs. For example, the functional modules in the various embodiments of this application may be integrated into one processing module, or each module may exist physically separately, or two or more modules may be integrated into one module.

[0099] The above are merely specific embodiments of this application, but the scope of protection of this application is not limited thereto. Any variations or substitutions that can be easily conceived by those skilled in the art within the scope of the technology disclosed in this application should be included within the scope of protection of this application. Therefore, the scope of protection of this application should be determined by the scope of the claims.

Claims

1. A service discovery method, characterized in that, include: Receive a service subscription event sent by a client, wherein the service subscription event includes the client's access information and the subscribed service information; Based on the service information, query the server on the in-vehicle node that matches the service subscription event and the access information of the server; Based on the access information of the server and the access information of the client, determine whether the server is located on the internal component of the in-vehicle node and whether the client is located on the in-vehicle node; Based on the judgment result, the access information of the server is processed to distinguish between external use and local use, and then pushed to the client so that the client can communicate with the server based on the differentiated access information; The step of distinguishing between external and local use of the server's access information based on the judgment result before pushing it to the client includes: If the determination result is that the server is located on the internal component of the in-vehicle node and the client is not located on the in-vehicle node, then based on the preset conversion mapping rule, the access information of the server is converted into the external network access information of the in-vehicle node and pushed to the client, so that the client can communicate with the server based on the external network access information of the in-vehicle node; If the determination result is that the server is located on the internal component of the in-vehicle node and the client is located on the in-vehicle node, then the access information of the server is pushed to the client so that the client can communicate with the server based on the access information of the server. If the determination result indicates that the server is not located on the internal components of the in-vehicle node, then the access information of the server is pushed to the client so that the client can communicate with the server based on the access information of the server.

2. The method according to claim 1, characterized in that, The preset conversion mapping rules include preset network address translation rules. The step of converting the server's access information into the vehicle's external network access information based on these preset conversion mapping rules includes: If the access information of the server is the server's network address information, then based on the preset network address translation rule, the server's network address information is mapped and converted into the external network address information of the in-vehicle node.

3. The method according to claim 1, characterized in that, The preset conversion mapping rules include preset network address port conversion rules. The step of converting the server's access information into the vehicle's external network access information based on these preset conversion mapping rules includes: If the access information of the server is the server's network address and port information, then based on the preset network address and port conversion rules, the server's network address and port information is mapped and converted into the external network address and port information of the in-vehicle node.

4. The method according to claim 1, characterized in that, The step of determining whether the server is located on an internal component of the in-vehicle node and whether the client is located on the in-vehicle node based on the access information of the server and the access information of the client includes: The access information of the server is compared with the external network access information of the in-vehicle node to determine whether the server is located on the internal component of the in-vehicle node. The client's access information is compared with the external access information of the in-vehicle node to determine whether the client is located on the in-vehicle node.

5. A service discovery device, characterized in that, The device includes: The receiving module is used to receive service subscription events sent by the client, wherein the service subscription event includes the client's access information and subscribed service information; The query module is used to query the server on the in-vehicle node that matches the service subscription event and the access information of the server, based on the service information. The judgment module is used to determine whether the server is located on the internal component of the in-vehicle node and whether the client is located on the in-vehicle node based on the access information of the server and the access information of the client. The processing module is used to distinguish between external and local use of the access information of the server based on the judgment result and then push it to the client so that the client can communicate with the server based on the distinguished access information. The processing module is configured to: if the determination result indicates that the server is located on an internal component of the in-vehicle node and the client is not located on the in-vehicle node, then based on a preset conversion mapping rule, convert the server's access information into the in-vehicle node's external network access information and push it to the client, so that the client can communicate with the server based on the in-vehicle node's external network access information; if the determination result indicates that the server is located on an internal component of the in-vehicle node and the client is located on the in-vehicle node, then push the server's access information to the client, so that the client can communicate with the server based on the server's access information; if the determination result indicates that the server is not located on an internal component of the in-vehicle node, then push the server's access information to the client, so that the client can communicate with the server based on the server's access information.

6. An electronic device, characterized in that, include: A processor and a memory, the memory being used to store a computer program, the processor being used to invoke and run the computer program stored in the memory to perform the method of any one of claims 1-4.

7. A computer-readable storage medium, characterized in that, Used to store a computer program that causes a computer to perform the method as described in any one of claims 1-4.

Images