Data transmission method and related equipment

Abstract

The embodiment of the invention discloses a data transmission method and related equipment. The related equipment can comprise a data transmission device, electronic equipment, a computer program product and a computer readable storage medium. According to the embodiment of the invention, after a long connection process and a service process corresponding to the long connection process are constructed and a long connection request is sent to a business server through the long connection process, long connection login information corresponding to the long connection request returned by the business server is received, and then the long connection login information is sent to the business server based on the long connection login information. The method comprises the following steps: establishing a long connection between a first terminal and a second terminal corresponding to a service server in a long connection process, detecting the long connection through a service process so as to keep the long connection in a connected state, and then receiving at least one piece of target service data sent by the second terminal through the long connection in the connected state; according to the scheme, the data transmission efficiency can be improved.

Description

Technical Field

[0001] This invention relates to the field of communication technology, and more specifically to a data transmission method and related equipment, which may include data transmission devices, electronic devices, computer program products, and computer-readable storage media. Background Technology

[0002] In recent years, with the rapid development of internet technology, data transmission between different terminals has become increasingly convenient. In scenarios involving continuous data transmission, long-lived connections can often be established between terminals to improve data transmission efficiency, allowing for continuous data transmission.

[0003] In the process of researching and practicing current technologies, the inventors of this application have discovered that in mobile networks, the network status is complex and changeable, which often leads to the interruption of long connections in some cases, thereby affecting data transmission between terminals and resulting in low data transmission efficiency. Summary of the Invention

[0004] This application provides a data transmission method and related equipment. The related equipment may include a data transmission device, an electronic device, a computer program product, and a computer-readable storage medium, which can improve the efficiency of data transmission.

[0005] A data transmission method, comprising:

[0006] Establish a long-connection process and a corresponding service process, and send a long-connection request to the business server through the long-connection process;

[0007] Receive the long connection login information corresponding to the long connection request returned by the business server;

[0008] Based on the long connection login information, a long connection is established between the first terminal and the second terminal corresponding to the business server in the long connection process;

[0009] The long connection is detected by the service process to keep the long connection in a connected state;

[0010] The long connection, which is in a connected state, receives at least one target service data sent by the second terminal.

[0011] Accordingly, embodiments of this application provide a data transmission apparatus, including:

[0012] The sending unit is used to construct a long connection process and a service process corresponding to the long connection process, and to send a long connection request to the business server through the long connection process.

[0013] The first receiving unit is used to receive the long connection login information corresponding to the long connection request returned by the business server;

[0014] An establishment unit is used to establish a long connection between the first terminal and the second terminal corresponding to the business server in the long connection process based on the long connection login information.

[0015] The detection unit is used to detect the long connection through the service process in order to keep the long connection in a connected state;

[0016] The second receiving unit is configured to receive at least one target service data sent by the second terminal through the long connection which is in a connected state.

[0017] In some embodiments, the detection unit may be specifically used to detect the long connection process through the service process to obtain a process detection result; to detect the network corresponding to the long connection through the service process to obtain a network detection result; and to maintain the long connection in a connected state based on the process detection result and the network detection result.

[0018] In some embodiments, the detection unit may be specifically used to detect the process state of the long connection process through the service process to obtain the current process state of the long connection process; when the current process state indicates that the long connection process is alive, send at least one heartbeat packet to the long connection process through the service process according to the target heartbeat time interval; and detect the first response packet of the heartbeat packet to obtain the process detection result.

[0019] In some embodiments, the detection unit may be specifically used to send a preset number of heartbeat packets to the long connection process through the service process according to a preset first heartbeat time interval; when a second response packet of the heartbeat packet is received, the service process sends the heartbeat packet to the long connection process according to a preset second heartbeat time interval, wherein the second heartbeat time interval is greater than the preset first heartbeat time interval; and adjust the preset second heartbeat time interval based on a third response packet of the heartbeat packet to obtain a target heartbeat time interval.

[0020] In some embodiments, the detection unit may be specifically used to, when receiving the third return packet of the heartbeat packet returned by the long connection process, increase the preset second heartbeat time interval to obtain an increased heartbeat time interval, and use the increased heartbeat time interval as the preset second heartbeat time interval; return to execute the step of sending the heartbeat packet to the long connection process through the service process according to the preset heartbeat time interval, until no third return packet is received, and use the preset second heartbeat time interval corresponding to the last received third return packet as a candidate heartbeat time interval; subtract the preset time interval value from the time interval value of the candidate heartbeat time interval to obtain the target heartbeat time interval.

[0021] In some embodiments, the detection unit may be specifically used to restart the long connection process when the current process state indicates that the long connection process has been killed, and to rebuild the long connection in the long connection process based on the long connection response information; to send at least one heartbeat packet to the rebuilt long connection through the service process according to the target heartbeat time interval; and to detect the first response packet of the heartbeat packet to obtain the process detection result.

[0022] In some embodiments, the detection unit may be specifically used to determine that the long connection is in a failed state when the process detection result indicates that the first return packet has not been received for a preset number of consecutive times, or when the network detection result indicates that the network has switched; rebuild the long connection in the long connection process, and return to execute the step of detecting the long connection process through the service process, so as to keep the long connection in a connected state.

[0023] In some embodiments, the sending unit may be specifically used to obtain terminal parameters of the first terminal and a first object identifier of the target object logging into the target application on the first terminal; encrypt the terminal parameters and the first object identifier to obtain encrypted request parameters, and generate a long connection request, wherein the long connection request carries the encrypted request parameters; send the long connection request to the gateway server through the long connection process, so that the gateway server can perform signature authentication on the long connection request, and forward the long connection request to the service server based on the authentication result.

[0024] In some embodiments, the sending unit may be specifically used to encrypt the terminal parameters and the first object identifier according to a preset encryption protocol to obtain initial encrypted request parameters; and to encrypt the initial encrypted request parameters based on a preset encryption algorithm to obtain encrypted request parameters.

[0025] In some embodiments, the sending unit may be specifically used to encrypt the request body of the long connection request to obtain an initial encrypted long connection request; add an encryption identifier to the request header of the initial encrypted long connection request to obtain an encrypted long connection request; and send the encrypted long connection request to the gateway server through the long connection process so that the gateway server can decrypt and authenticate the encrypted long connection request, and forward the decrypted long connection request to the service server based on the decryption and authentication results.

[0026] In some embodiments, the data transmission device may further include a binding unit, which is specifically configured to: obtain an access token for the second object identifier of the target object logging into the target application on the second terminal; send the access token to an account server corresponding to the first terminal, so that the account server binds the first object identifier and the second object identifier; receive the binding result returned by the account server, and update the login status of the second object identifier logging into the target application on the first terminal based on the binding result; the long connection construction process and the service process corresponding to the long connection process include: when the login status is updated to logged in, constructing the long connection process and the service process corresponding to the long connection process.

[0027] In some embodiments, the binding unit may be specifically used to send a binding request to the account server when the target object is detected to be performing a login operation, and receive a login token of the target application returned by the account server based on the binding request; send the login token to the application server of the target application, and receive an object login identifier corresponding to the second object identifier returned by the application server; display the object login identifier so that the second terminal can send the verification information of the second object identifier for logging into the target application to the application server by scanning the object login identifier; and receive an access token of the second object identifier returned by the application server.

[0028] In some embodiments, the establishment unit may be specifically used to decrypt the long connection login information to obtain long connection information, and to authenticate the long connection information; when the long connection information is authenticated, a long connection establishment request for the second terminal is sent to the service server through the long connection process; when the long connection response information of the long connection establishment request is received from the service server, a long connection is established between the first terminal and the second terminal in the long connection process.

[0029] In some embodiments, the second receiving unit may be specifically configured to send a data subscription request to the service server, the data subscription request carrying subscription parameters indicating at least one service type of the received service data; receive subscription response information of the data subscription request returned by the service server, and determine the subscription status of the service data for the second terminal based on the subscription response information; when the subscription status indicates successful subscription, receive at least one current service data returned by the service server through the long connection in the connected state, the current service data including at least one service data corresponding to the service type sent by the second terminal to the service server; and parse the current service data to obtain target service data.

[0030] In some embodiments, the data transmission device may further include an unbinding unit, which may be specifically configured to send a first logout request to the account server corresponding to the first terminal, so that the account server sends an unbinding request for the long connection to the business server; receive first unbinding information returned by the business server based on the unbinding request, and parse the first unbinding information to obtain parsed first unbinding information; based on the parsed first unbinding information, disconnect the long connection in the long connection process, and destroy the information of the long connection and the information of the long connection process.

[0031] In some embodiments, the unbinding unit may be specifically used to parse the second unbinding information returned by the service server based on the second logout request sent by the second terminal when receiving the second unbinding information, to obtain the parsed second unbinding information; based on the parsed second unbinding information, to disconnect the long connection in the long connection process, and to destroy the information of the long connection and the information of the long connection process.

[0032] Furthermore, embodiments of this application also provide an electronic device, including a processor and a memory, wherein the memory stores an application program, and the processor is used to run the application program in the memory to execute the data transmission method provided in embodiments of this application.

[0033] Furthermore, embodiments of this application also provide a computer-readable storage medium storing a plurality of instructions adapted for loading by a processor to execute steps in any of the data transmission methods provided in embodiments of this application.

[0034] Furthermore, embodiments of this application also provide a computer program product, including a computer program or instructions, which, when executed by a processor, implement the steps in the data transmission method provided in embodiments of this application.

[0035] This embodiment of the application constructs a long-connection process and a corresponding service process. After sending a long-connection request to the business server through the long-connection process, it receives the long-connection login information corresponding to the long-connection request returned by the business server. Then, based on the long-connection login information, it establishes a long-connection between the first terminal and the second terminal corresponding to the business server in the long-connection process. The service process detects the long-connection to keep it in a connected state. Then, it receives at least one target service data sent by the second terminal through the connected long-connection. Since this scheme can construct a long-connection and a corresponding service process, build the long-connection in an independent long-connection process, and realize the network interaction of the long-connection through this process, it reduces the probability of the long-connection process being killed, thereby reducing the probability of the long-connection being disconnected. In addition, the long-connection can be detected by the corresponding service process to keep it in a connected state, improving the stability of the long-connection. Therefore, it can improve the efficiency of data transmission. Attached Figure Description

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

[0037] Figure 1 This is a schematic diagram of a scenario illustrating the data transmission method provided in an embodiment of this application;

[0038] Figure 2 This is a flowchart illustrating the data transmission method provided in an embodiment of this application;

[0039] Figure 3 This is a schematic diagram illustrating the account binding process between the vehicle-mounted terminal and the mobile terminal provided in this application embodiment;

[0040] Figure 4 This is a schematic diagram illustrating two request methods for sending long-connection requests as provided in the embodiments of this application;

[0041] Figure 5 This is a schematic diagram illustrating data interaction between a long-connection process and a service process via a target component, provided in an embodiment of this application.

[0042] Figure 6 This is a schematic diagram of the overall process of data transmission between the vehicle terminal and the mobile device provided in the embodiments of this application;

[0043] Figure 7 This is another schematic flowchart of the data transmission method provided in the embodiments of this application;

[0044] Figure 8 This is a schematic diagram of the structure of the data transmission device provided in the embodiments of this application;

[0045] Figure 9 This is another structural schematic diagram of the data transmission device provided in the embodiments of this application;

[0046] Figure 10 This is another structural schematic diagram of the data transmission device provided in the embodiments of this application;

[0047] Figure 11 This is a schematic diagram of the structure of the electronic device provided in the embodiments of this application. Detailed Implementation

[0048] 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 the present invention, and not all embodiments. Based on the embodiments of the present invention, all other embodiments obtained by those skilled in the art without creative effort are within the scope of protection of the present invention.

[0049] This application provides a data transmission method and related equipment, which may include a data transmission device, an electronic device, a computer program product, and a computer-readable storage medium. The data transmission device may be integrated into an electronic device, which may be a server or a terminal, etc.

[0050] The server can be a standalone physical server, a server cluster or distributed system composed of multiple physical servers, or a cloud server providing basic cloud computing services such as cloud services, cloud databases, cloud computing, cloud functions, cloud storage, network services, cloud communication, middleware services, domain name services, security services, content delivery network (CDN), and big data and artificial intelligence platforms. The terminal can be a smartphone, tablet, laptop, desktop computer, smart speaker, smartwatch, etc., but is not limited to these. The terminal and server can be directly or indirectly connected via wired or wireless communication, which is not limited herein.

[0051] For example, see Figure 1Taking the integration of a data transmission device into an electronic device as an example, the electronic device can construct a long connection process and a corresponding service process. After sending a long connection request to the business server through the long connection process, it receives the long connection login information corresponding to the long connection request returned by the business server. Then, based on the long connection login information, a long connection is established between the first terminal and the second terminal corresponding to the business server in the long connection process. The service process detects the long connection to keep it in a connected state. Then, it receives at least one business data sent by the second terminal through the long connection in the connected state, thereby improving the efficiency of data transmission.

[0052] It is understood that, in the specific embodiments of this application, data related to objects or business data, etc., when the following embodiments of this application are applied to specific products or technologies, permission or consent is required, and the collection, use and processing of related data must comply with the relevant laws, regulations and standards of the relevant countries and regions.

[0053] The following sections provide detailed descriptions of each example. It should be noted that the order in which the embodiments are described is not intended to limit the preferred order of the embodiments.

[0054] This embodiment will be described from the perspective of a data transmission device, which can be integrated into an electronic device, such as a server or a terminal. The terminal can include tablet computers, laptops, personal computers (PCs), wearable devices, virtual reality devices, or other smart devices capable of data transmission.

[0055] A data transmission method, applied to a first terminal, includes:

[0056] A long-connection process and its corresponding service process are constructed. The long-connection process sends a long-connection request to the business server and receives the long-connection login information corresponding to the long-connection request returned by the business server. Based on the long-connection login information, a long-connection is established between the first terminal and the second terminal corresponding to the business server in the long-connection process. The service process detects the long-connection to keep it in a connected state. At least one piece of business data sent by the second terminal is received through the long-connection in a connected state.

[0057] like Figure 2 As shown, this data transmission method is applied to the first terminal, and the specific process of the data transmission method is as follows:

[0058] 101. Construct a long-connection process and its corresponding service process, and send a long-connection request to the business server through the long-connection process.

[0059] The long-connection process can be understood as a process that stores long-connection logic and establishes long-connections and performs data transmission through that logic. Since long-connection processes only perform network interactions, they consume fewer resources, reducing the likelihood of system garbage collection.

[0060] Service processes can be understood as background processes running in the operating system, providing various services to the system or applications, such as network services, system monitoring, and logging. The service processes corresponding to long-connection processes can be understood as processes that monitor and transmit data for long-connection processes; they can also be called long-connection daemons.

[0061] In this context, a long-connection request can be understood as a request to establish a long-connection connection. This request is used to retrieve the long-connection login information returned by the business server for establishing the long-connection. The long-connection login information can be summarized as the login username (username) and password (password) required to establish a long-connection with the second terminal corresponding to the business server.

[0062] There are several ways to establish a long-connection process and its corresponding service process, and to send long-connection requests to the business server through the long-connection process. These methods can be as follows:

[0063] S1. Construct the long-connection process and the corresponding service process.

[0064] For example, a process instance can be created directly, and the long connection logic can be extracted into that process instance to obtain the long connection process. A background process can be created and configured to obtain the configured background process. The configured background process can detect the process status of the long connection process, communicate with the long connection process, and detect the network status of the long connection process. The configured background process can be used as the service process corresponding to the long connection process.

[0065] Optionally, in some embodiments, before constructing the long-connection process and the corresponding service process, the first object identifier logged in by the target object on the first terminal can be bound to the second object identifier logged in by the target object on the second terminal where a long connection needs to be established. There are various binding methods. For example, an access token for the second object identifier of the target object logged into the target application on the second terminal can be obtained, and the access token can be sent to the account server corresponding to the first terminal. The account server can then bind the first object identifier and the second object identifier, receive the binding result returned by the account server, and update the login status of the second object identifier logged into the target application on the first terminal based on the binding result. When the login status is updated to "logged in," the long-connection process and the corresponding service process are constructed.

[0066] An access token can be understood as a credential or token used to access and authorize third-party applications to access a target user's object identifier on a target application. For example, taking a social media application as the target application, the access token could be a credential or token used to access and authorize third-party applications to access social media accounts (SNS Access Token). There are several ways to obtain the access token for the second object identifier of the target user logging into the target application on a second terminal. For example, when a login operation is detected, a binding request is sent to the account server, and the login token of the target application returned by the account server based on the binding request is received. The login token is then sent to the application server of the target application, and the object login identifier corresponding to the second object identifier returned by the application server is received. The object login identifier is displayed so that the second terminal can scan the object login identifier to send the second object identifier of the target application to the application server and receive the access token of the second object identifier returned by the application server.

[0067] The binding request can be a request to bind object identifiers between a first terminal and a second terminal. When a login operation is detected on the target object, there are several ways to send a binding request to the account server. For example, a login page can be displayed, which includes a login control corresponding to the identifier type of the second object. In response to the triggering of the login control, a binding request is sent to the account server.

[0068] It should be noted that the second object identifier can be understood as the object identifier of the target application logged in by the target object on the second terminal. The object identifier can be of various types, such as an account, ID, or other identifying information that can indicate the identity of the target object. The first terminal may or may not contain the target application.

[0069] After sending a binding request to the account server, the account server returns a login token for the target application based on the binding request. A login token can be understood as a token used to obtain an object login identifier for the target application.

[0070] After receiving the login token for the target application from the account server, the login token can be sent to the target application's application server to receive the object login identifier corresponding to the second object identifier returned by the application server. The application server may include the platform server of the target application's development platform and the target application's Software Development Kit (SDK). The platform server can provide the SDK interface. The object login identifier can be an identifier used by the second object to log in to the target application on the first terminal. For example, taking QR code login as an example, the object login identifier can be a one-dimensional barcode, a two-dimensional barcode, or other types of login codes, etc. There are several ways to send the login token to the target application's application server and receive the object login identifier corresponding to the second object identifier returned by the application server. For example, the login token can be sent to the platform server, and the platform server can receive the SDK login ticket returned based on the login token. Based on the login ticket, a login request can be sent to the SDK, and then the object login identifier corresponding to the second object identifier returned by the SDK can be received.

[0071] After receiving the object login identifier corresponding to the second object identifier returned by the SDK, the object identifier can be displayed so that the second terminal can scan the object login identifier and send the verification information of the second object identifier for logging into the target application to the application server. There are several ways for the second terminal to send the verification information of the second object identifier for logging into the target application to the application server by scanning the object login identifier. For example, the second terminal can collect the object login identifier, generate verification information for logging in on the first terminal based on the object login identifier, and send the verification information to the SDK. The SDK can then send the access token of the second object identifier to the first terminal based on the verification information, thereby enabling the first terminal to receive the access token of the second object identifier.

[0072] After receiving the access token for the second object identifier, the access token can be sent to the account server corresponding to the first terminal so that the account server can bind the first object identifier and the second object identifier. The binding result returned by the account server is received, and based on the binding result, the login status of the second object identifier on the target application on the first terminal is updated. There are several ways to update the login status of the second object identifier on the target application on the first terminal. For example, when the binding result indicates that the first object identifier and the second object identifier are successfully bound, the login status of the second object identifier on the target application on the first terminal is updated to "logged in," and a login notification message is displayed.

[0073] When the login status of the target application on the first terminal is updated to "logged in", a long connection process and the corresponding service process are constructed.

[0074] Optionally, in some embodiments, after the account server receives a binding request, it can periodically request an access token from the platform server. The platform server then returns the access token to the account server, which stores the access token. It should be noted that each time a new access token is obtained, the account server updates the historical access tokens to the latest one, thus ensuring that the latest access token is returned to the first terminal after receiving a binding request.

[0075] In this example, taking the vehicle-mounted infotainment system as the first terminal and the mobile terminal as the second terminal, the first object identifier as the target object's first account on the vehicle-mounted infotainment system, the second object identifier as the target object's second account on the mobile terminal, and the object login identifier as a QR code, the account binding process between the vehicle-mounted infotainment system and the mobile terminal can be as follows: Figure 3 As shown, the specific details are as follows:

[0076] (1) The account server requests a timed token from the platform server, the platform server returns the token, and the account server saves the token;

[0077] (2) The target object enters the vehicle login page and sends a binding request to the account server through the first terminal, thereby requesting a token;

[0078] (3) The account server returns the login token corresponding to the platform server;

[0079] (4) The first terminal obtains the SDK login ticket from the platform server based on the access token;

[0080] (5) Request a QR code from the SDK based on the information of the target object obtained by scanning the code, and display the QR code;

[0081] (6) Users log in by scanning a QR code using a mobile terminal;

[0082] (7) The SDK returns an access token (sns accessToken);

[0083] (8) After the user is verified, an access token is issued to request the account server to bind the account (bind the first account to the second account);

[0084] (10) Log in on the vehicle terminal and store relevant information.

[0085] Taking the vehicle-mounted infotainment system as an example, this solution obtains the QR code for logging into the vehicle-mounted infotainment system from the second object identifier corresponding to the mobile terminal via the interface provided by the target application's platform server. The mobile terminal logs in by scanning the code, completing the binding of the first and second accounts. Then, when the target application logged into the second account on the mobile terminal logs in, the target application on the mobile terminal and the target application on the vehicle-mounted infotainment system can be combined through a long connection scheme to complete data transmission and business processing on the vehicle-mounted infotainment system. This provides significant benefits for software deployment on the vehicle-mounted infotainment system, primarily improving the convenience of interconnection between the in-vehicle system and mobile terminal applications, thereby increasing the transmission efficiency of data between the vehicle-mounted infotainment system and the mobile terminal. Taking a navigation application as an example, the established long connection can send navigation information from the navigation application on the mobile terminal to the navigation application on the vehicle-mounted infotainment system, improving road usage efficiency and safety during navigation and enhancing the user's travel experience.

[0086] S2. Send a long connection request to the business server through the long connection process.

[0087] For example, the terminal parameters of the first terminal and the first object identifier of the target object when logging into the target application on the first terminal can be obtained. The terminal parameters and the first object identifier are encrypted to obtain encrypted request parameters and generate a long connection request. The long connection request carries the encrypted request parameters and is sent to the gateway server through the long connection process so that the gateway server can sign and authenticate the long connection request and send the long connection request to the business server based on the authentication result.

[0088] Terminal parameters can be understood as parameters related to various attributes of the terminal, such as terminal identifier, type, or other parameters that indicate the terminal's identity. The first object identifier can be understood as the object identifier of the target object logging into the target application on the first terminal. For example, taking the first terminal as an in-vehicle infotainment system, the first object identifier could be the account used by the target object to log into the target application on the in-vehicle infotainment system. There are several ways to obtain the terminal parameters of the first terminal and the first object identifier of the target object logging into the target application on the first terminal. For example, one can read the attribute information of the first terminal to obtain the terminal parameters, send an object identifier read request to the account server, and receive the first object identifier returned by the account server indicating that the target object has logged into the target application on the first terminal.

[0089] After obtaining the terminal parameters of the first terminal and the first object identifier of the target object logged into the target application on the first terminal, the terminal parameters and the first object identifier can be encrypted to obtain the encrypted request parameters. There are several ways to encrypt the terminal parameters and the first object identifier. For example, the terminal parameters and the first object identifier can be encrypted according to a preset encryption protocol to obtain the initial encrypted request parameters, and then the initial encrypted request parameters can be encrypted again based on a preset encryption algorithm to obtain the encrypted request parameters.

[0090] The types of preset encryption protocols can be varied, such as JCE protocol or other encryption protocols, etc.

[0091] After encrypting the terminal parameters and the first object identifier according to a preset encryption protocol, the initially encrypted request parameters can be encrypted using a preset encryption algorithm to obtain the encrypted request parameters. There are several ways to encrypt the initially encrypted request parameters based on the preset encryption parameters. For example, the AES-256-CBC algorithm (an encryption algorithm) can be used to encrypt the initially encrypted request parameters at least once to obtain the encrypted request parameters. Alternatively, other encryption algorithms besides the preset encryption protocol can be used to encrypt the initially encrypted request parameters at least once to obtain the encrypted request parameters.

[0092] It should be noted that the terminal parameters and the first object identifier will be encrypted at least twice, and the two encryption methods are different.

[0093] After encrypting the terminal parameters and the first object identifier, a long connection request can be generated, which carries the encrypted request parameters.

[0094] After generating a long connection request, the long connection process can send the long connection request to the gateway server so that the gateway server can sign and authenticate the long connection request and forward it to the business server based on the authentication result.

[0095] In this process, the long connection request is sent to the gateway server in plaintext through the long connection process. The gateway server authenticates the signature of the long connection request. If the authentication fails, it returns a failure message to the first terminal. If the signature authentication is successful, the long connection request can be forwarded to the business server.

[0096] Optionally, in some embodiments, after generating the long-connection request, the long-connection request can also be sent to the gateway server in encrypted form so that the gateway server can authenticate the encrypted long-connection request. For example, the request header of the long-connection request is encrypted to obtain an initial encrypted long-connection request. An encryption identifier is added to the request header of the initial encrypted long-connection request to obtain an encrypted long-connection request. The encrypted long-connection request is then sent to the gateway server through the long-connection process so that the gateway server can decrypt and sign the encrypted long-connection request for authentication. Based on the decryption and authentication results, the gateway server forwards the decrypted long-connection request to the business server.

[0097] There are several ways for the gateway to forward the decrypted long connection request to the business server based on the decryption and authentication results. For example, after the gateway server successfully decrypts the encrypted long connection request and passes the signature verification, it forwards the decrypted long connection request to the business server.

[0098] It should be noted that the gateway server will return an error message when it fails to decrypt the encrypted long connection request or when the signature verification fails.

[0099] After receiving a long-connection request, the business server can return the corresponding long-connection login information to the gateway server. The gateway server encrypts the long-connection login information and sends the encrypted information to the first terminal, thereby achieving long-connection authentication.

[0100] Taking the JCE protocol (an encryption protocol) as the preset encryption protocol, the AES-256-CBC algorithm as the preset encryption algorithm, the device ID as the terminal parameter, and the user ID as the first object identifier as an example, the overall process of long-connection authentication can include: encrypting the user ID and device ID parameters using the JCE protocol, then performing a second encryption using the AES-256-CBC algorithm to request authentication from the gateway server. After successful decryption and verification of the request's legitimacy, the gateway server forwards the user ID and device ID to the business server. At this point, the business server sends the username and password (long-connection login information) required for the long connection to the gateway server. The gateway server returns the encrypted username and password to the first terminal. After receiving the decrypted username and password, the first terminal initiates a long-connection login request through the long-connection process. During the long-connection request process, both plaintext and encrypted requests can be included, as detailed below. Figure 4 As shown:

[0101] (1) Plain Request

[0102] The first terminal sends a long-connection request containing the user ID and device ID to the gateway server in plaintext. The gateway server performs signature authentication; if it fails, it returns an error message (e.g., 403 or other error messages). If the signature authentication is successful, it forwards the long-connection request to the business server. The business server responds and returns the long-connection login information to the gateway server. The gateway server then returns the long-connection login information to the first terminal.

[0103] (2) Encryption Request

[0104] The first terminal encrypts the body of the long-connection request and adds an encryption identifier to the request header, thus obtaining an encrypted long-connection request, which is then sent to the gateway server. The gateway server decrypts and authenticates the encrypted long-connection request. If decryption or authentication fails, an error is reported. If decryption and authentication are successful, the gateway server forwards the decrypted long-connection request to the business server. The business server responds and returns the long-connection login information to the gateway server. The gateway server then encrypts the long-connection login information and returns it to the first terminal.

[0105] This solution can encrypt long-connection requests using encryption algorithms and parameter signatures, thereby ensuring the security of data transmission and providing a better user experience and functionality for various application scenarios.

[0106] 102. Receive the long-connection login information corresponding to the long-connection request returned by the business server.

[0107] The long-connection login information may include the login account (use name) and key (password) used to establish the long connection.

[0108] There are several ways to receive the long-connection login information corresponding to the long-connection request returned by the business server, as follows:

[0109] For example, it can receive encrypted request-response information returned by the business server through the gateway server to obtain long-connection login information, or it can directly receive request-response information returned by the business server and use that response information as long-connection login information, and so on.

[0110] 103. Based on the long-connection login information, establish a long connection between the first terminal and the second terminal corresponding to the business server during the long-connection process.

[0111] For example, the long connection login information is decrypted to obtain the long connection information, and the long connection information is authenticated. When the long connection information is successfully authenticated, a long connection establishment request for the second terminal is sent to the business server through the long connection process. When the long connection response information of the long connection establishment request is received from the business server, a long connection is established between the first terminal and the second terminal in the long connection process.

[0112] There are several ways to decrypt long-connection login information. For example, the target component can output a response identifier when the long-connection login information fails, and the long-connection login information can be decrypted based on the response identifier to obtain the long-connection information.

[0113] The target component can be an SDK that enables cross-terminal long-connection solutions. Its main responsibility is to inject MQTT network capabilities into the Android layer, encapsulate them through JNI, and pass them to the C++ layer for message transmission and parsing. The Pangu C++ layer is mainly responsible for user authentication, encrypted data assembly, generation of valid tokens, gateway authentication services, and other functions, thus realizing a secure and efficient SDK.

[0114] After decrypting the long-connection login information, authentication can be performed on the decrypted information. When authentication is successful, a long-connection establishment request for the second terminal is sent to the business server via the long-connection process. Upon receiving the long-connection response from the business server, a long-connection connection can be established between the first and second terminals within the long-connection process. This long-connection can be a long-connection under MQTT (a lightweight communication protocol), or a long-connection under other communication protocols, etc.

[0115] 104. The service process detects long-lived connections to keep them in a connected state.

[0116] For example, the service process can detect the long-connection process and obtain the process detection result. The service process can also detect the network corresponding to the long-connection and obtain the network detection result. Based on the process detection result and the network detection result, the long-connection is kept in the connected state. Specifically, it can be done as follows:

[0117] (1) The long connection is detected by the service process, and the process detection result is obtained.

[0118] For example, the process status of a long-connection process can be detected by the service process to obtain the current process status of the long-connection process. When the current process status indicates that the long-connection process is alive, at least one heartbeat packet is sent to the long-connection process by the service process according to the target heartbeat time interval. The first response of the heartbeat packet is detected to obtain the process detection result.

[0119] The current process state can be understood as the process state of the long-connection process during detection. The process state can include status information indicating whether the process is alive. There are several ways to detect the process state of a long-connection process through a service process. For example, the service process can obtain the current running information of the long-connection process and identify its process state from this information to obtain the current process state.

[0120] After the service process checks the process status of the long-connection process, when the current process status indicates that the long-connection process is alive, the service process can send at least one heartbeat packet to the long-connection process according to the target heartbeat interval. There are several ways to send at least one heartbeat packet to the long-connection process through the service process according to the target heartbeat interval. For example, the service process can send one heartbeat packet to the long-connection process, and when the interval reaches the target heartbeat interval, it can send another heartbeat packet to the long-connection process through the service process, and so on.

[0121] Optionally, in some embodiments, the target heartbeat time interval can be determined before the service process sends at least one heartbeat packet to the long-connection process based on the target heartbeat time interval. There are several ways to determine the target heartbeat time interval. For example, based on a preset first heartbeat time interval, the service process can send a preset number of heartbeat packets to the long-connection process. When a second response packet is received, the service process sends a heartbeat packet to the long-connection process based on a preset second heartbeat time interval. Based on a third response packet, the preset second heartbeat time interval is adjusted to obtain the target heartbeat time interval.

[0122] The heartbeat packet can include pre-configured files or custom commands used for the heartbeat mechanism. The first response to the heartbeat packet can be understood as the content returned by the long-connection process after receiving the heartbeat packet sent by the service process, according to the conventions of the heartbeat mechanism.

[0123] The preset second heartbeat time interval is greater than the preset first heartbeat time interval. Based on the third return packet of the heartbeat packet, there are several ways to adjust the preset second heartbeat time interval. For example, when the third return packet of the heartbeat packet returned by the long-connection process is received, the preset second heartbeat time interval is increased to obtain the increased heartbeat time interval. This increased heartbeat time interval is then used as the preset second heartbeat time interval. The process of sending heartbeat packets to the long-connection process through the service process according to the preset heartbeat time interval is then resumed until no third return packet is received. The preset second heartbeat time interval corresponding to the last received third return packet is then used as a candidate heartbeat time interval. The time interval of the candidate heartbeat time interval is then subtracted from the preset time interval value to obtain the target heartbeat time interval.

[0124] The preset time interval is a pre-defined time interval value, which can be a small value, such as 0.1 seconds, 0.2 seconds, 0.5 seconds, 1 second, 2 seconds, 5 seconds, 10 seconds, or other values. If a third packet is not received, it can be understood that the heartbeat interval at this point has failed in the test. In this case, to quickly restore the heartbeat mechanism, it is necessary to find the last successfully tested heartbeat interval and then use a heartbeat interval slightly shorter than this successful heartbeat interval as the target heartbeat interval. It should be noted that choosing a heartbeat interval slightly shorter than the last successfully tested heartbeat interval is to increase fault tolerance, thereby ensuring the long-connection heartbeat mechanism returns to normal operation as quickly as possible.

[0125] It's important to note that a longer heartbeat interval results in less load and energy consumption. In this solution, after finding an effective heartbeat interval, this interval can be actively increased. Then, the success of the increased heartbeat interval is tested. If the test fails (i.e., no third packet is received), a slightly shorter heartbeat interval than the previous successful one is used as the target heartbeat interval. If the test succeeds, the heartbeat interval can be increased further until a usable effective interval (the maximum usable target heartbeat interval) can be found. Taking a preset first heartbeat interval of 60 seconds and an increase of 30 seconds as an example, the entire detection process to determine the target heartbeat interval can include: sending a short heartbeat of 60 seconds three times consecutively, starting the detection, testing for 90 seconds, increasing to 120 seconds if the test is successful, increasing to 150 seconds if the test is successful, and so on, to find the target heartbeat interval.

[0126] After the service process sends at least one heartbeat packet to the long-connection process, the first response to the heartbeat packet can be detected to obtain the process detection result. There are several ways to detect the first response to the heartbeat packet. For example, it is possible to count whether the first response to the heartbeat packet is received, and if the first response is not received, to count the number of consecutive times the first response is not received, thereby obtaining the process detection result.

[0127] Optionally, in some embodiments, after the service process detects the process state of the long connection process and obtains the current process state of the long connection process, if the long connection process is killed after the current process state, the long connection process can be restarted, and the long connection can be rebuilt in the long connection process based on the long connection response information. According to the target heartbeat time interval, the service process sends at least one heartbeat packet to the rebuilt long connection process, and the first response packet of the heartbeat packet is detected to obtain the process detection result.

[0128] There are several ways to restart a long-lived connection process. For example, you can restart the long-lived connection process directly through the target component, or you can rebuild the long-lived connection process, and so on.

[0129] After restarting the persistent connection process, the persistent connection can be rebuilt within the persistent connection process based on the persistent connection response information. The process of rebuilding the persistent connection is the same as the process of establishing a persistent connection within the persistent connection process, as described above, and will not be repeated here.

[0130] After re-establishing the long-connection process, at least one heartbeat packet can be sent to the re-established long-connection process through the service process according to the target heartbeat time interval. The first response packet of this heartbeat packet is then detected to obtain the process detection result. The process of detecting the first response packet of the heartbeat packet can be referred to the above description, and will not be repeated here.

[0131] (2) The network corresponding to the long connection is detected by the service process to obtain the network detection results.

[0132] For example, the network status of the network corresponding to the long connection can be detected by the service process to detect whether the network corresponding to the long connection has switched, thereby obtaining the network detection result.

[0133] In this context, the network corresponding to a long connection can be understood as the communication network used by a long connection or a long connection process when conducting network communication.

[0134] (3) Based on the process detection results and network detection results, keep the long connection in the connected state.

[0135] For example, when the process detection result indicates that the first packet has not been received for a preset number of consecutive times, or when the network detection result indicates that the network has switched, it is determined that the long connection is in an invalid state. The long connection is rebuilt in the long connection process, and the process returns to execute the step of detecting the long connection process through the service process in order to keep the long connection in a connected state.

[0136] The preset number of times can be understood as a pre-defined number of consecutive times the first heartbeat packet is not received. For example, it could include 2, 3, 4, 5, 6, 8, 10, or any other arbitrary number. When the process detection result indicates that the first heartbeat packet has not been received for the preset number of consecutive times, or when the network detection structure indicates that a network switch has occurred, it can be determined that the long connection has failed, i.e., it is in a failed state. At this time, in order to keep the long connection in a connected state, it is necessary to reconnect the long connection, that is, to rebuild the long connection during the long connection process.

[0137] After re-establishing the long connection in the long connection process, the process can return to the step of detecting the long connection process through the service process to detect the status of the long connection. If the long connection is detected to be in an invalid state, the reconnection continues until it is detected to be in a connected state. When it is detected to be in a connected state, the process returns to the step of detecting the long connection process and the network corresponding to the long connection through the service process. This can keep the long connection in a connected state, improve the stability of the long connection, and improve the transmission efficiency of data transmission.

[0138] This solution utilizes long-connection mechanisms such as process keep-alive, heartbeat, and reconnection after disconnection to maintain the connection in an established state, thereby improving long-term communication efficiency (transmission efficiency) and achieving practicality and real-time communication. Within the long-connection process, data interaction between the target component and the service process can be achieved, thus maintaining the connection in an established state within the long connection. Specifically, this can be done as follows: Figure 5 As shown. The target component can provide an SDK that implements a long-connection solution process. It primarily injects MQTT network capabilities into the Android layer, encapsulates them via JNI, and passes them to the C++ layer for message transmission and parsing. The C++ layer of the target component is mainly responsible for user authentication, encrypted data assembly, generating valid tokens, and gateway authentication services, thus implementing a secure and efficient SDK. The service process (i.e., the long-connection daemon) monitors the long-connection process's state and maintains its liveness through adaptive heartbeats. Additionally, the service process can detect network conditions to determine the long-connection status.

[0139] 105. Receive at least one service data sent by a second terminal through a long connection that is already in a connected state.

[0140] In this context, business data can be understood as the data required by the primary terminal to execute business operations. For example, taking navigation as an example, business data could include navigation location information, time information, or other data that can support navigation operations, and so on.

[0141] There are several ways to receive at least one service data sent by the second terminal through a long-connection that is already in a connected state, including the following:

[0142] For example, a data subscription request can be sent to a service server, carrying subscription parameters indicating at least one service type of the received service data. The service server returns subscription response information for the data subscription request, and based on the subscription response information, the subscription status of the service data for the second terminal is determined. When the subscription status indicates successful subscription, at least one current service data returned by the service server is received through the long connection that is in a connected state. The current service data includes at least one service data corresponding to the service type sent by the second terminal to the service server. The current service data is parsed to obtain the target service data.

[0143] A data subscription request can be understood as a request to subscribe to service data from a second terminal. The data subscription request carries subscription parameters, which indicate at least one service type of the received service data. It should be noted that the second terminal can contain multiple types of service data; however, the first terminal does not need to receive all service types within a single long-lived connection. By using subscription parameters to select the service data that the first terminal can receive, other service data is prevented from occupying the long-lived connection for transmission, thereby improving data transmission efficiency.

[0144] After sending a data subscription request to the service server, the system can receive the subscription response information returned by the service server. Based on this response information, the subscription status of the service data for the second terminal can be determined. The subscription response information can be understood as the response information returned by the service server in response to the data subscription request. This response information indicates the permission to receive service data corresponding to the subscription parameters. There are several ways to determine the subscription status of the service data for the second terminal based on the subscription response information. For example, upon receiving the subscription response information, the subscription status of the service data for the second terminal can be determined to be successful. Alternatively, the reception permission for each service type in the subscription parameters can be identified in the subscription response information; when the reception permission indicates that reception is allowed, the subscription status of the service data for the second terminal can be determined to be successful, and so on.

[0145] Once the subscription status indicates successful subscription, at least one piece of current service data can be received from the service server through a long-connected connection. This current service data includes at least one piece of service data corresponding to the service type sent by the second terminal to the service server. The entire receiving process can include: when the second terminal sends at least one piece of service data corresponding to the service type to the service server, it can receive the service data returned by the service server, thus obtaining the unparsed current service data. The service server can either return the service data sent by the second terminal as current service data to the first terminal in real time, or it can cache the service data sent by the second terminal and return the cached service data corresponding to that service request as current service data when the first terminal sends a service request.

[0146] It should be noted that a long connection in a connected state can continuously receive at least one current service data corresponding to the service type sent by the second terminal back by the service service.

[0147] After receiving at least one piece of current business data returned by the business server through a persistent connection that is already established, the current business data can be parsed to obtain the target business data. There are several ways to parse the current business data. For example, it can be parsed through the target component to obtain the target business data, or it can be parsed through the JCE protocol to obtain the target business data, and so on.

[0148] Optionally, in some embodiments, after receiving at least one target service data sent by the second terminal through a long-connected connection, the long connection can be unbound. There are several ways to unbind the long connection. For example, a first logout request can be sent to the account server corresponding to the first terminal, so that the account server sends an unbinding request for the long connection to the service server. The service server then receives the first unbinding information returned by the unbinding request, parses the first unbinding information to obtain parsed first unbinding information, and based on the parsed first unbinding information, disconnects the long connection in the long connection process and destroys the information of the long connection and the long connection process. Alternatively, when the service server receives the second unbinding information returned by the second logout request sent by the second terminal, the second unbinding information is parsed to obtain parsed second unbinding information, and based on the parsed second unbinding information, the long connection is disconnected in the long connection process, and the information of the long connection and the long connection process is destroyed, and so on.

[0149] During the process of unbinding long connections, it can be observed that both the first terminal and the second terminal can trigger the unbinding.

[0150] This solution utilizes stable and secure long-lived connections for data transmission. Taking a map navigation application as the target application, the vehicle map account as the first object identifier, the gateway server as the middleware gateway, the business server as the middleware service, and the mobile terminal as the second terminal, the first terminal can include the in-vehicle map client (vehicle map client) and the target component (SDK). The overall data transmission process can be as follows: Figure 6 As shown, the specific details are as follows:

[0151] (1) Log in to the CarMap client and bind the CarMap account to the account of the second terminal (see above for details of the binding and login process), inject MQTT long connection capability into the target component, and inject long connection network capability setMQTTClient(IMQTTClientCallback callback), register business detection permission registerPushMsgListener(IPushMsglistener listener);

[0152] (2) The vehicle diagram client requests long connection authentication from the target component via PushMessage init(userid, deviceld);

[0153] (3) The target component encrypts and signs the parameters of the long connection request (long-connect / author, encrypted header, body (userid)) and sends the request to the middleware gateway;

[0154] (4) The middleware gateway successfully decrypts and verifies the validity of the parameter signature, and forwards the relevant request parameters to the middleware service;

[0155] (5) The middleware service sends the username and password (i.e., long connection login information) of the long connection WSS login to the middleware gateway;

[0156] (6) The middleware gateway encrypts and returns the username and password of the WSS login to the target component;

[0157] (7) The target component decrypts the long connection login information and returns the decrypted long connection information to the vehicle map client;

[0158] (8) After the vehicle diagram client obtains the long connection information, it performs authentication (i.e., the authentication callback onInitResult(ReturnMessage ret, PushConnectionOptions options)). After successful authentication, it initiates a long connection request connect(int reqld, PushConnections options, PushActionCallback callback).

[0159] (9) The vehicle map client completes the long connection request with the middleware service, that is, through the middleware service, a long connection (MQTT long connection wss) is established between the vehicle map client and the mobile terminal, and the target component is notified that the long connection is successfully established (PushActionCallback notifyConnected(int request);

[0160] (10) The target component initiates a data subscription request: subscribe(int request, String topic, PushActionCallback callback);

[0161] (11) The middleware service returns a successful subscription to the vehicle map client. The vehicle map client notifies the target component that the subscription is successful: PushActionCallback notifySubscriptionComplete(int reqld). The target component waits for the mobile terminal to send a message (business data) through the middleware service.

[0162] (12) When the mobile terminal sends business data to the middleware service, the middleware service sends the business data to the vehicle map client. The vehicle map client sends the business data to the target component IMQTTClientCallback handleMessageArrived(int reqld, String topic, byte[], payload). The target component completes the parsing of the business data and returns the parsed business data as the target business data to the vehicle map client (business callback IPushMsgListeneronNotifyMsgParsed(info));

[0163] (13) The middleware service pushes unbinding information to the vehicle map client based on the unbinding request sent by the mobile terminal. The vehicle map client sends the unbinding information to the target component IMQTTClientCallback handleMessageArrived(int reqld, String topic, byte[], payload). Alternatively, the vehicle map client sends an unbinding request to the middleware service. The middleware service pushes the corresponding unbinding information to the vehicle map client based on the unbinding request. The vehicle map client sends the unbinding information to the target component IMQTTClientCallback handleMessageArrived(int reqld, String topic, byte[], payload).

[0164] (14) The target component parses the unbinding message and notifies the vehicle map client to unbind the long connection IMQTTClientCallback disconnect(int reqld, PushActionCallback callback);

[0165] (15) After the vehicle diagram client unbinds the long connection, it can notify the target component that the disconnect was successful by PushActionCallback notifySubscriptionComplete(int reqld) and destroy the information of the long connection and the information of the long connection process (PushMessage destroy).

[0166] As can be seen from the above, in this embodiment of the application, after constructing a long connection process and a corresponding service process, and sending a long connection request to the business server through the long connection process, the long connection login information corresponding to the long connection request returned by the business server is received. Then, based on the long connection login information, a long connection is established between the first terminal and the second terminal corresponding to the business server in the long connection process. The long connection is detected by the service process to keep the long connection in a connected state. Then, at least one target service data sent by the second terminal is received through the long connection in a connected state. Since this scheme can construct a long connection and a corresponding service process, construct the long connection in an independent long connection process, and realize the network interaction of the long connection through this process, the probability of the long connection process being killed is reduced, thereby reducing the probability of the long connection being disconnected. In addition, the long connection can be detected by the corresponding service process to keep the long connection in a connected state, thus improving the stability of the long connection. Therefore, the efficiency of data transmission can be improved.

[0167] Based on the method described in the above embodiments, the following examples will provide further detailed explanations.

[0168] In this embodiment, the data transmission is specifically integrated into an electronic device, which is the first terminal, the first terminal being an in-vehicle terminal (i.e., the vehicle-mounted terminal), the second terminal being a mobile terminal, the first object identifier being the first account for logging into the target application on the in-vehicle terminal, the second object identifier being the second account for logging into the target application on the mobile terminal, and the object login identifier being a login QR code, as an example for explanation.

[0169] like Figure 7 As shown, a data transmission method has the following specific process:

[0170] 201. The vehicle terminal establishes a long connection process and the corresponding service process.

[0171] For example, the vehicle terminal can directly create a process instance and extract the long connection logic into the process instance to obtain the long connection process. It can also create a background process and configure it to obtain the configured background process. The configured background process can detect the process status of the long connection process, communicate with the long connection process, and detect the network status of the long connection process. The configured background process can then be used as the service process corresponding to the long connection process.

[0172] Optionally, in some embodiments, when the vehicle terminal detects a login operation by a target object, it displays a login page. This login page includes a login control corresponding to the identifier type of the second account. In response to the triggering of the login control, it sends a binding request to the account server. It receives a login token for the target application returned by the account server based on the binding request. The login token is sent to the platform server, and the platform server returns a login ticket for the SDK based on the login token. Based on the login ticket, a login request is sent to the SDK, and the login QR code corresponding to the second account returned by the SDK is received and displayed.

[0173] The mobile terminal collects the login QR code and generates verification information for the second account to log in on the vehicle terminal based on the login QR code. The verification information is sent to the SDK so that the SDK can send the access token of the second account to the vehicle terminal based on the verification information, thereby enabling the vehicle terminal to receive the access token of the second account.

[0174] The vehicle terminal sends the access token to the account server corresponding to the vehicle terminal, so that the account server can bind the first account and the second account. It then receives the binding result returned by the account server. When the binding result indicates that the first account and the second account are successfully bound, the login status of the second account on the target application on the vehicle terminal is updated to "logged in," and a "logged in" message is displayed.

[0175] When the login status of the second account logging into the target application on the vehicle terminal is updated to "logged in", a long connection process and the corresponding service process are constructed.

[0176] Optionally, in some embodiments, after the account server receives the binding request, the account server may also periodically request an access token from the platform server, the platform server returns the access token to the account server, and the account server stores the access token.

[0177] 202. The vehicle terminal sends a long connection request to the business server through a long connection process.

[0178] For example, the vehicle-mounted terminal can read its attribute information to obtain terminal parameters, send an object identifier read request to the account server, and receive the first account returned by the account server for the target object to log in to the target application on the vehicle-mounted terminal. The terminal parameters and the first account are then encrypted using the JCE protocol to obtain the initially encrypted request parameters.

[0179] The vehicle terminal can use the AES-256-CBC algorithm (an encryption algorithm) to encrypt the initially encrypted request parameters at least once to obtain the encrypted request parameters. Alternatively, it can use other encryption algorithms other than the preset encryption protocol to encrypt the initially encrypted request parameters at least once to obtain the encrypted request parameters.

[0180] The vehicle-mounted terminal generates a long-connection request based on the encrypted request parameters. This long-connection request carries the encrypted request parameters. The long-connection process sends the long-connection request to the gateway server, so that the gateway server can sign and authenticate the long-connection request, and forward the long-connection request to the business server based on the authentication result.

[0181] Optionally, in some embodiments, the vehicle terminal can also encrypt the request of the long connection request to obtain an initial encrypted long connection request, add an encryption identifier to the request header of the initial encrypted long connection request to obtain an encrypted long connection request, and send the encrypted long connection request to the gateway server through the long connection process so that the gateway server can decrypt and authenticate the encrypted long connection request. After the encrypted long connection request is successfully decrypted and the signature verification is passed, the decrypted long connection request is forwarded to the business server.

[0182] Optionally, in some embodiments, if the gateway server fails to decrypt the encrypted long connection request or fails the signature verification, it returns an error message to the vehicle terminal.

[0183] 203. The vehicle terminal receives the long connection login information corresponding to the long connection request returned by the service server.

[0184] For example, the vehicle terminal can receive encrypted request-response information returned by the business server through the gateway server to obtain long-connection login information, or it can directly receive request-response information returned by the business server and use the response information as long-connection login information, and so on.

[0185] 204. The vehicle terminal establishes a long connection between the vehicle terminal and the mobile terminal corresponding to the business server during the long connection process based on the long connection login information.

[0186] For example, the vehicle terminal can obtain the response identifier from the failed long-connection login information through the target component, and decrypt the long-connection login information based on the response identifier to obtain the long-connection information.

[0187] The vehicle-mounted terminal can authenticate the decrypted long connection information. When the authentication is successful, it sends a long connection establishment request for the mobile terminal to the business server through the long connection process. When it receives the long connection establishment request response information from the business server, a long connection can be established between the vehicle-mounted terminal and the mobile terminal in the long connection process. This long connection can be a long connection under MQTT (a lightweight communication protocol).

[0188] 205. The vehicle terminal detects long connections through the service process and obtains the process detection results.

[0189] For example, the vehicle terminal can obtain the current process running information of the long connection process through the service process, identify the process state of the long connection process in the current process running information, and thus obtain the current process state.

[0190] The vehicle terminal can send a heartbeat packet to the long connection process through the service process. When the interval reaches the target heartbeat interval, it will continue to send a heartbeat packet to the long connection process through the service process, and so on.

[0191] The vehicle-mounted terminal can count whether the first heartbeat packet has been received. If the first heartbeat packet is not received, the number of consecutive times the first heartbeat packet is not received can be counted to obtain the process detection result.

[0192] Optionally, in some embodiments, when the long-connection process is killed after the current process state, the vehicle terminal can directly restart the long-connection process through the target component, or it can rebuild the long-connection process, and so on.

[0193] Based on the long connection response information, the vehicle terminal reconstructs the long connection during the long connection process. According to the target heartbeat time interval, it sends at least one heartbeat packet to the reconstructed long connection process through the service process. The first response packet of the heartbeat packet is detected to obtain the process detection result.

[0194] Optionally, in some embodiments, the vehicle terminal may also send a preset number of heartbeat packets to the long-connection process through the service process according to a preset first heartbeat time interval. When a second heartbeat packet is received, a heartbeat packet is sent to the long-connection process through the service process according to the preset second heartbeat time interval. When a third heartbeat packet is received from the long-connection process, the preset second heartbeat time interval is increased to obtain an increased heartbeat time interval, and this increased heartbeat time interval is used as the preset second heartbeat time interval. The process then returns to the step of sending heartbeat packets to the long-connection process through the service process according to the preset heartbeat time interval, until no third heartbeat packet is received. The preset second heartbeat time interval corresponding to the last received third heartbeat packet is used as a candidate heartbeat time interval, and the time interval of the candidate heartbeat time interval is subtracted from the preset time interval value to obtain the target heartbeat time interval.

[0195] 206. The vehicle terminal detects the network corresponding to the long connection through the service process and obtains the network detection results.

[0196] For example, the vehicle terminal can detect the network status of the network corresponding to the long connection through the service process, detect whether the network corresponding to the long connection has switched, and thus obtain the network detection result.

[0197] 207. The vehicle terminal maintains the long connection in a connected state based on the process detection results and network detection results.

[0198] For example, when the process detection result indicates that the first packet has not been received for a preset number of consecutive times, or when the network detection result indicates that the network has switched, the vehicle terminal determines that the long connection is in an invalid state, rebuilds the long connection in the long connection process, and returns to execute the step of detecting the long connection process through the service process in order to keep the long connection in a connected state.

[0199] 208. The vehicle-mounted terminal receives at least one service data sent by the mobile terminal through a long connection that is already in a connected state.

[0200] For example, the vehicle terminal can send a data subscription request to the service server, which carries subscription parameters indicating at least one service type of the received service data, and receive subscription response information of the data subscription request returned by the service server.

[0201] When the vehicle terminal receives the subscription response information, it can determine that the subscription status of the service data for the mobile terminal is successful. Alternatively, it can identify the receiving permission for each service type in the subscription parameters in the subscription response information. When the receiving permission indicates that receiving is allowed, it can determine that the subscription status of the service data for the mobile terminal is successful, and so on.

[0202] When the subscription status indicates successful subscription, the vehicle terminal receives at least one current service data returned by the service server through the long connection that is in a connected state. The current service data includes at least one service data corresponding to the service type sent by the mobile terminal to the service server.

[0203] The vehicle terminal can parse the current business data through the target component to obtain the target business data, or it can parse the current business data through the JCE protocol to obtain the target business data, and so on.

[0204] Optionally, in some embodiments, the vehicle terminal may send a first logout request to the account server corresponding to the vehicle terminal, so that the account server sends an unbinding request for the long connection to the business server, receives the first unbinding information returned by the business server based on the unbinding request, parses the first unbinding information to obtain parsed first unbinding information, disconnects the long connection in the long connection process based on the parsed first unbinding information, and destroys the information of the long connection and the information of the long connection process.

[0205] In some embodiments, when the vehicle terminal receives the second unbinding information returned by the service server based on the second logout request sent by the mobile terminal, it parses the second unbinding information to obtain the parsed second unbinding information. Based on the parsed second unbinding information, it disconnects the long connection in the long connection process and destroys the information of the long connection and the information of the long connection process.

[0206] As can be seen from the above, in this embodiment, the vehicle terminal constructs a long connection process and a corresponding service process, sends a long connection request to the service server through the long connection process, receives the long connection login information corresponding to the long connection request returned by the service server, and then establishes a long connection between the vehicle terminal and the mobile terminal corresponding to the service server in the long connection process based on the long connection login information. The service process detects the long connection to keep it in a connected state. Then, it receives at least one target service data sent by the mobile terminal through the long connection in a connected state. Since this scheme can construct a long connection and a corresponding service process, construct the long connection in an independent long connection process, and realize the network interaction of the long connection through this process, the probability of the long connection process being killed is reduced, thereby reducing the probability of the long connection being disconnected. In addition, the long connection can be detected by the corresponding service process to keep it in a connected state, improving the stability of the long connection. Therefore, the efficiency of data transmission can be improved.

[0207] To better implement the above methods, embodiments of this application also provide a data transmission device, which can be integrated into an electronic device, such as a server or terminal. The terminal may include a tablet computer, a laptop computer, and / or a personal computer.

[0208] For example, such as Figure 8 As shown, the data transmission device may include a transmitting unit 301, a first receiving unit 302, an establishing unit 303, a detection unit 304, and a second receiving unit 305, as follows:

[0209] (1) Transmitting unit 301;

[0210] The sending unit 301 is used to construct a long connection process and a corresponding service process, and to send a long connection request to the business server through the long connection process.

[0211] For example, the sending unit 301 can be specifically used to construct a long connection process and a service process corresponding to the long connection process, obtain the terminal parameters of the first terminal and the first object identifier of the target object when logging into the target application on the first terminal, encrypt the terminal parameters and the first object identifier to obtain encrypted request parameters, and generate a long connection request. The long connection request carries the encrypted request parameters and is sent to the gateway server through the long connection process so that the gateway server can sign and authenticate the long connection request, and send the long connection request to the business server based on the authentication result.

[0212] (2) First receiving unit 302;

[0213] The first receiving unit 302 is used to receive the long connection login information corresponding to the long connection request returned by the business server.

[0214] For example, the first receiving unit 302 can be used to receive the encrypted request response information returned by the business server through the gateway server, and obtain the long connection login information.

[0215] (3) Establish unit 303;

[0216] Establishment unit 303 is used to establish a long connection between the first terminal and the second terminal corresponding to the business server during the long connection process based on the long connection login information.

[0217] For example, the establishment unit 303 can be used to decrypt the long connection login information to obtain the long connection information and authenticate the long connection information. When the long connection information is successfully authenticated, a long connection establishment request for the second terminal is sent to the business server through the long connection process. When the long connection response information of the long connection establishment request returned by the business server is received, a long connection is established between the first terminal and the second terminal in the long connection process.

[0218] (4) Detection unit 304;

[0219] The detection unit 304 is used to detect long connections through the service process in order to keep the long connection in the connected state.

[0220] For example, the detection unit 304 can specifically be used to detect the process status of the long connection process through the service process to obtain the current process status of the long connection process. When the current process status indicates that the long connection process is alive, the service process sends at least one heartbeat packet to the long connection process according to the target heartbeat time interval, and detects the first response packet of the heartbeat packet to obtain the process detection result. The service process detects the network status of the network corresponding to the long connection to detect whether the network corresponding to the long connection has switched, thereby obtaining the network detection result. When the process detection result indicates that the first response packet has not been received for a preset number of consecutive times, or when the network detection result indicates that the network has switched, it is determined that the long connection is in a failed state. The long connection is rebuilt in the long connection process, and the process returns to execute the step of detecting the long connection process through the service process to keep the long connection in a connected state.

[0221] (5) Second receiving unit 305;

[0222] The second receiving unit 305 is configured to receive at least one target service data sent by the second terminal through a long connection in a connected state.

[0223] For example, the second receiving unit 305 can be specifically used to send a data subscription request to a service server. The data subscription request carries subscription parameters, which indicate at least one service type of the received service data. It receives subscription response information of the data subscription request returned by the service server, and determines the subscription status of the service data for the second terminal based on the subscription response information. When the subscription status indicates successful subscription, it receives at least one current service data returned by the service server through the long connection that is in a connected state. The current service data includes at least one service data corresponding to the service type sent by the second terminal to the service server. It parses the current service data to obtain the target service data.

[0224] Optionally, in some embodiments, the data transmission device may further include a binding unit 306, such as... Figure 9 As shown, the specific details are as follows:

[0225] Binding unit 306 is used to bind the first object identifier of the target application logged in on the second terminal to the first object identifier logged in on the first terminal.

[0226] For example, the binding unit 306 can be used to obtain the access token of the second object identifier of the target object when logging into the target application on the second terminal, send the access token to the account server corresponding to the first terminal, so that the account server can bind the first object identifier and the second object identifier, receive the binding result returned by the account server, and update the login status of the second object identifier when logging into the target application on the first terminal based on the binding result.

[0227] Optionally, in some embodiments, the data transmission device may further include an unbinding unit 307, such as... Figure 10 As shown, the specific details are as follows:

[0228] The unbinding unit 307 is used to unbind the first object identifier of the target application logged in on the second terminal from the first object identifier logged in on the first terminal.

[0229] For example, the unbinding unit 307 can be specifically used to send a first logout request to the account server corresponding to the first terminal, so that the account server sends an unbinding request for the long connection to the business server, receives the first unbinding information returned by the business server based on the unbinding request, parses the first unbinding information to obtain the parsed first unbinding information, disconnects the long connection in the long connection process based on the parsed first unbinding information, and destroys the information of the long connection and the information of the long connection process; or, when receiving the second unbinding information returned by the business server based on the second logout request sent by the second terminal, parses the second unbinding information to obtain the parsed second unbinding information, disconnects the long connection in the long connection process based on the parsed second unbinding information, and destroys the information of the long connection and the information of the long connection process.

[0230] In practice, each of the above units can be implemented as an independent entity or can be arbitrarily combined to be implemented as the same or several entities. For the specific implementation of each of the above units, please refer to the previous method embodiments, which will not be repeated here.

[0231] As can be seen from the above, in this embodiment of the application, after the sending unit 301 constructs a long connection process and a corresponding service process for the long connection process, and sends a long connection request to the service server through the long connection process, the first receiving unit 302 receives the long connection login information corresponding to the long connection request returned by the service server. Then, the establishment unit 303 establishes a long connection between the first terminal and the second terminal corresponding to the service server in the long connection process based on the long connection login information. The detection unit 304 detects the long connection through the service process to keep the long connection in a connected state. Then, the second receiving unit 305 receives at least one target service data sent by the second terminal through the long connection in a connected state. Since this scheme can construct a long connection and a corresponding service process for the long connection, construct the long connection in an independent long connection process, and realize the network interaction of the long connection through this process, the probability of the long connection process being killed is reduced, thereby reducing the probability of the long connection being disconnected. In addition, the long connection can also be detected through the corresponding service process to keep the long connection in a connected state, thereby improving the stability of the long connection. Therefore, the efficiency of data transmission can be improved.

[0232] This application also provides an electronic device, such as... Figure 11 As shown, it illustrates a structural schematic diagram of the electronic device involved in the embodiments of this application, specifically:

[0233] The electronic device may include components such as a processor 401 with one or more processing cores, a memory 402 with one or more computer-readable storage media, a power supply 403, and an input unit 404. Those skilled in the art will understand that... Figure 11 The electronic device structure shown does not constitute a limitation on the electronic device and may include more or fewer components than shown, or combine certain components, or have different component arrangements. Wherein:

[0234] The processor 401 is the control center of the electronic device, connecting various parts of the device via various interfaces and lines. It executes software programs and / or modules stored in the memory 402, and calls data stored in the memory 402, to perform various functions and process data. Optionally, the processor 401 may include one or more processing cores; preferably, the processor 401 may integrate an application processor and a modem processor, wherein the application processor mainly handles the operating system, user interface, and applications, and the modem processor mainly handles wireless communication. It is understood that the modem processor may not be integrated into the processor 401.

[0235] The memory 402 can be used to store software programs and modules. The processor 401 executes various functional applications and data processing by running the software programs and modules stored in the memory 402. The memory 402 may mainly include a program storage area and a data storage area. The program storage area may store the operating system, application programs required for at least one function (such as sound playback function, image playback function, etc.), etc.; the data storage area may store data created according to the use of the electronic device, etc. In addition, the memory 402 may include high-speed random access memory, and may also include non-volatile memory, such as at least one disk storage device, flash memory device, or other volatile solid-state storage device. Accordingly, the memory 402 may also include a memory controller to provide the processor 401 with access to the memory 402.

[0236] The electronic device also includes a power supply 403 that supplies power to the various components. Preferably, the power supply 403 can be logically connected to the processor 401 through a power management system, thereby enabling functions such as charging, discharging, and power consumption management through the power management system. The power supply 403 may also include one or more DC or AC power supplies, recharging systems, power fault detection circuits, power converters or inverters, power status indicators, and other arbitrary components.

[0237] The electronic device may also include an input unit 404, which can be used to receive input digital or character information, and generate keyboard, mouse, joystick, optical or trackball signal inputs related to user settings and function control.

[0238] Although not shown, the electronic device may also include a display unit, etc., which will not be described in detail here. Specifically, in this embodiment, the processor 401 in the electronic device loads the executable files corresponding to the processes of one or more applications into the memory 402 according to the following instructions, and the processor 401 runs the applications stored in the memory 402 to realize various functions, as follows:

[0239] A long-connection process and its corresponding service process are constructed. The long-connection process sends a long-connection request to the business server and receives the long-connection login information corresponding to the long-connection request returned by the business server. Based on the long-connection login information, a long-connection is established between the first terminal and the second terminal corresponding to the business server in the long-connection process. The service process detects the long-connection to keep it in a connected state. At least one piece of business data sent by the second terminal is received through the long-connection in a connected state.

[0240] For example, an electronic device can construct a long-connection process and a corresponding service process. It obtains the terminal parameters of the first terminal and the first object identifier of the target object logging into the target application on the first terminal. The terminal parameters and the first object identifier are encrypted to obtain encrypted request parameters, and a long-connection request is generated. This long-connection request carries the encrypted request parameters and is sent to the gateway server through the long-connection process. The gateway server then signs and authenticates the long-connection request and, based on the authentication result, sends it to the business server. The business server receives the encrypted request response information returned by the gateway server to obtain the long-connection login information. The long-connection login information is decrypted to obtain the long-connection information, which is then authenticated. When the long-connection information is successfully authenticated, a long-connection establishment request for the second terminal is sent to the business server through the long-connection process. When the long-connection establishment request response information is received from the business server, a long-connection between the first and second terminals is established within the long-connection process. The service process monitors the process status of the long-connection process to obtain its current state. When the current state indicates that the long-connection process is alive, the service process sends at least one heartbeat packet to the long-connection process according to the target heartbeat interval. The first response to the heartbeat packet is then monitored to obtain the process monitoring result. The service process also monitors the network status of the network corresponding to the long-connection to determine if a network switch has occurred, thus obtaining the network monitoring result. If the process monitoring result indicates that the first response packet has not been received for a preset number of consecutive times, or if the network monitoring result indicates that a network switch has occurred, the long-connection is determined to be in an invalid state. The long-connection process is then rebuilt, and the process returns to the step of monitoring the long-connection process through the service process to maintain the long-connection in a connected state. A data subscription request is sent to the service server, the data subscription request carrying subscription parameters indicating at least one service type of the received service data. The subscription response information of the data subscription request returned by the service server is received, and based on the subscription response information, the subscription status of the service data for the second terminal is determined. When the subscription status indicates successful subscription, at least one current service data returned by the service server is received through the long connection that is in a connected state. The current service data includes at least one service data corresponding to the service type sent by the second terminal to the service server. The current service data is parsed to obtain the target service data.

[0241] For details on the implementation of each of the above operations, please refer to the previous examples, which will not be repeated here.

[0242] As can be seen from the above, in this embodiment of the application, after constructing a long connection process and a corresponding service process, and sending a long connection request to the business server through the long connection process, the long connection login information corresponding to the long connection request returned by the business server is received. Then, based on the long connection login information, a long connection is established between the first terminal and the second terminal corresponding to the business server in the long connection process. The long connection is detected by the service process to keep the long connection in a connected state. Then, at least one target service data sent by the second terminal is received through the long connection in a connected state. Since this scheme can construct a long connection and a corresponding service process, construct the long connection in an independent long connection process, and realize the network interaction of the long connection through this process, the probability of the long connection process being killed is reduced, thereby reducing the probability of the long connection being disconnected. In addition, the long connection can be detected by the corresponding service process to keep the long connection in a connected state, thus improving the stability of the long connection. Therefore, the efficiency of data transmission can be improved.

[0243] Those skilled in the art will understand that all or part of the steps in the various methods of the above embodiments can be performed by instructions, or by instructions controlling related hardware. These instructions can be stored in a computer-readable storage medium and loaded and executed by a processor.

[0244] Therefore, embodiments of this application provide a computer-readable storage medium storing a plurality of instructions that can be loaded by a processor to execute steps in any of the data transmission methods provided in embodiments of this application. For example, the instructions can execute the following steps:

[0245] A long-connection process and its corresponding service process are constructed. The long-connection process sends a long-connection request to the business server and receives the long-connection login information corresponding to the long-connection request returned by the business server. Based on the long-connection login information, a long-connection is established between the first terminal and the second terminal corresponding to the business server in the long-connection process. The service process detects the long-connection to keep it in a connected state. At least one piece of business data sent by the second terminal is received through the long-connection in a connected state.

[0246] For example, a long-connection process and its corresponding service process are constructed. Terminal parameters of the first terminal and the first object identifier of the target object logging into the target application on the first terminal are obtained. The terminal parameters and the first object identifier are encrypted to obtain encrypted request parameters, and a long-connection request is generated. This long-connection request carries the encrypted request parameters and is sent to the gateway server through the long-connection process. The gateway server authenticates the long-connection request and, based on the authentication result, sends it to the business server. The encrypted request response information returned by the business server through the gateway server is received to obtain the long-connection login information. The long-connection login information is decrypted to obtain the long-connection information, which is then authenticated. When the long-connection information is successfully authenticated, a long-connection establishment request for the second terminal is sent to the business server through the long-connection process. When the long-connection response information for the long-connection establishment request is received from the business server, a long-connection between the first and second terminals is established within the long-connection process. The service process monitors the process status of the long-connection process to obtain its current state. When the current state indicates that the long-connection process is alive, the service process sends at least one heartbeat packet to the long-connection process according to the target heartbeat interval. The first response to the heartbeat packet is then monitored to obtain the process monitoring result. The service process also monitors the network status of the network corresponding to the long-connection to determine if a network switch has occurred, thus obtaining the network monitoring result. If the process monitoring result indicates that the first response packet has not been received for a preset number of consecutive times, or if the network monitoring result indicates that a network switch has occurred, the long-connection is determined to be in an invalid state. The long-connection process is then rebuilt, and the process returns to the step of monitoring the long-connection process through the service process to maintain the long-connection in a connected state. A data subscription request is sent to the service server, the data subscription request carrying subscription parameters indicating at least one service type of the received service data. The subscription response information of the data subscription request returned by the service server is received, and based on the subscription response information, the subscription status of the service data for the second terminal is determined. When the subscription status indicates successful subscription, at least one current service data returned by the service server is received through the long connection that is in a connected state. The current service data includes at least one service data corresponding to the service type sent by the second terminal to the service server. The current service data is parsed to obtain the target service data.

[0247] For details on the implementation of each of the above operations, please refer to the previous examples, which will not be repeated here.

[0248] The computer-readable storage medium may include: read-only memory (ROM), random access memory (RAM), disk or optical disk, etc.

[0249] Since the instructions stored in the computer-readable storage medium can execute the steps of any of the data transmission methods provided in the embodiments of this application, the beneficial effects that any of the data transmission methods provided in the embodiments of this application can achieve can be realized, as detailed in the preceding embodiments, and will not be repeated here.

[0250] According to one aspect of this application, a computer program product or computer program is provided, comprising computer instructions stored in a computer-readable storage medium. A processor of an electronic device reads the computer instructions from the computer-readable storage medium and executes the computer instructions, causing the electronic device to perform the methods provided in various alternative implementations of the data transmission aspect or data transmission via a long connection.

[0251] The foregoing has provided a detailed description of a data transmission method and related equipment provided in the embodiments of this application. The related equipment may include data transmission devices, electronic devices, computer program products, and computer-readable storage media. Specific examples have been used to illustrate the principles and implementation methods of the present invention. The description of the above embodiments is only for the purpose of helping to understand the method and core ideas of the present invention. At the same time, for those skilled in the art, there will be changes in specific implementation methods and application scope based on the ideas of the present invention. Therefore, the content of this specification should not be construed as a limitation of the present invention.

Claims

1. A data transmission method, characterized in that, Applied to the first terminal, including: Establish a long-connection process and a corresponding service process, and send a long-connection request to the business server through the long-connection process; Receive the long connection login information corresponding to the long connection request returned by the business server; Based on the long connection login information, a long connection is established between the first terminal and the second terminal corresponding to the business server in the long connection process; The long connection is detected by the service process to keep the long connection in a connected state; The long connection, which is in a connected state, receives at least one target service data sent by the second terminal.

2. The data transmission method according to claim 1, characterized in that, The step of detecting the long connection through the service process to keep the long connection in a connected state includes: The long-connection process is detected by the service process to obtain the process detection result; The service process detects the network corresponding to the long connection and obtains the network detection result. Based on the process detection results and network detection results, the long connection is kept in the connected state.

3. The data transmission method according to claim 2, characterized in that, The step of detecting the long-connection process through the service process to obtain the process detection result includes: The service process detects the process state of the long connection process to obtain the current process state of the long connection process. When the current process status indicates that the long-connection process is alive, at least one heartbeat packet is sent to the long-connection process through the service process according to the target heartbeat time interval; The first return packet of the heartbeat packet is detected to obtain the process detection result.

4. The data transmission method according to claim 3, characterized in that, Before sending at least one heartbeat packet to the long-connection process through the service process according to the target heartbeat time interval, the method further includes: According to a preset first heartbeat time interval, the service process sends a preset number of heartbeat packets to the long connection process. When the second response packet of the heartbeat packet is received, the heartbeat packet is sent to the long connection process through the service process according to the preset second heartbeat time interval, wherein the second heartbeat time interval is greater than the preset first heartbeat time interval; Based on the third return packet of the heartbeat packet, the preset second heartbeat time interval is adjusted to obtain the target heartbeat time interval.

5. The data transmission method according to claim 4, characterized in that, The third return packet based on the heartbeat packet adjusts the preset second heartbeat time interval to obtain the target heartbeat time interval, including: When the third return packet of the heartbeat packet returned by the long connection process is received, the preset second heartbeat time interval is increased to obtain the increased heartbeat time interval, and the increased heartbeat time interval is used as the preset second heartbeat time interval; Return to the step of sending the heartbeat packet to the long connection process through the service process according to the preset heartbeat time interval, until no third return packet is received, and use the preset second heartbeat time interval corresponding to the last received third return packet as the candidate heartbeat time interval; The target heartbeat time interval is obtained by subtracting the preset time interval value from the time interval value of the candidate heartbeat time interval.

6. The data transmission method according to claim 3, characterized in that, After obtaining the current process state of the long-connection process by detecting its process state through the service process, the method further includes: When the current process status indicates that the long connection process has been killed, the long connection process is restarted, and the long connection is rebuilt in the long connection process based on the long connection response information; Based on the target heartbeat time interval, at least one heartbeat packet is sent to the rebuilt long connection through the service process; The first return packet of the heartbeat packet is detected to obtain the process detection result.

7. The data transmission method according to claim 2, characterized in that, Maintaining the long connection in a connected state based on the process detection results and network detection results includes: When the process detection result indicates that the first packet has not been received for a preset number of consecutive times, or when the network detection result indicates that the network has switched, it is determined that the long connection is in a failed state. The long connection is rebuilt in the long connection process, and the process returns to the step of detecting the long connection process through the service process to keep the long connection in a connected state.

8. The data transmission method according to claim 1, characterized in that, Sending a long-connection request to the business server through the long-connection process includes: Obtain the terminal parameters of the first terminal and the first object identifier of the target object when logging into the target application on the first terminal; The terminal parameters and the first object identifier are encrypted to obtain encrypted request parameters, and a long connection request is generated, wherein the long connection request carries the encrypted request parameters. The long connection process sends the long connection request to the gateway server, so that the gateway server can sign and authenticate the long connection request, and forward the long connection request to the business server based on the authentication result.

9. The data transmission method according to claim 8, characterized in that, The step of encrypting the terminal parameters and the first object identifier to obtain encrypted request parameters includes: The terminal parameters and the first object identifier are encrypted according to a preset encryption protocol to obtain the initial encrypted request parameters; The initial encrypted request parameters are encrypted using a preset encryption algorithm to obtain the encrypted request parameters.

10. The data transmission method according to claim 8, characterized in that, After generating the long connection request, the process also includes: The request body of the long connection request is encrypted to obtain an initial encrypted long connection request; Add an encryption identifier to the request header of the initial encrypted long connection request to obtain the encrypted long connection request; The encrypted long connection request is sent to the gateway server through a long connection process, so that the gateway server can decrypt and authenticate the encrypted long connection request, and forward the decrypted long connection request to the business server based on the decryption and authentication results.

11. The data transmission method according to claim 8, characterized in that, Before the process for building the long-lived connection and the service process corresponding to the long-lived connection, the following steps are included: Obtain the access token of the second object identifier of the target object when logging into the target application on the second terminal; The access token is sent to the account server corresponding to the first terminal so that the account server can bind the first object identifier and the second object identifier. Receive the binding result returned by the account server, and update the login status of the second object identifier on the first terminal to log in to the target application based on the binding result; The process for building a long connection and the service process corresponding to the long connection process include: when the login status is updated to "login", building a long connection process and the service process corresponding to the long connection process.

12. The data transmission method according to claim 11, characterized in that, The step of obtaining the access token of the second object identifier of the target object for logging into the target application on the second terminal includes: When the target object is detected to be performing a login operation, a binding request is sent to the account server, and the login token of the target application is returned by the account server based on the binding request. The login token is sent to the application server of the target application, and the object login identifier corresponding to the second object identifier is received from the application server. The object login identifier is displayed so that the second terminal can send the verification information of the second object identifier for logging into the target application to the application server by scanning the object login identifier; Receive the access token of the second object identifier returned by the application server.

13. The data transmission method according to claim 1, characterized in that, The step of establishing a long connection between the first terminal and the second terminal corresponding to the business server during the long connection process based on the long connection login information includes: The long-connection login information is decrypted to obtain long-connection information, and the long-connection information is then authenticated. When the long connection information authentication is successful, a long connection establishment request for the second terminal is sent to the business server through the long connection process; When the long connection response information of the long connection establishment request returned by the service server is received, a long connection is established between the first terminal and the second terminal in the long connection process.

14. The data transmission method according to claim 1, characterized in that, Receiving at least one target service data sent by the second terminal through the long connection in a connected state includes: Send a data subscription request to the service server, the data subscription request carrying subscription parameters, the subscription parameters indicating at least one service type of the received service data; Receive subscription response information of the data subscription request returned by the service server, and determine the subscription status of the service data for the second terminal based on the subscription response information; When the subscription status indicates that the subscription is successful, at least one current service data returned by the service server is received through the long connection in the connected state. The current service data includes at least one service data corresponding to the service type sent by the second terminal to the service server. The current business data is parsed to obtain the target business data.

15. The data transmission method according to claim 1, characterized in that, After receiving at least one target service data sent by the second terminal through the long connection that is in a connected state, the method further includes: Send a first logout request to the account server corresponding to the first terminal, so that the account server can send an unbinding request for the long connection to the business server; Receive the first unbinding information returned by the business server based on the unbinding request, and parse the first unbinding information to obtain the parsed first unbinding information; Based on the parsed first unbinding information, the long connection is disconnected in the long connection process, and the information of the long connection and the information of the long connection process are destroyed.

16. The data transmission method according to claim 1, characterized in that, After receiving at least one target service data sent by the second terminal through the long connection that is in a connected state, the method further includes: When the second unbinding information returned by the business server based on the second logout request sent by the second terminal is received, the second unbinding information is parsed to obtain the parsed second unbinding information. Based on the parsed second unbinding information, the long connection is disconnected in the long connection process, and the information of the long connection and the information of the long connection process are destroyed.

17. A data transmission device, characterized in that, include: The sending unit is used to construct a long connection process and a service process corresponding to the long connection process, and to send a long connection request to the business server through the long connection process. The first receiving unit is used to receive the long connection login information corresponding to the long connection request returned by the business server; An establishment unit is used to establish a long connection between the first terminal and the second terminal corresponding to the business server in the long connection process based on the long connection login information. The detection unit is used to detect the long connection through the service process in order to keep the long connection in a connected state; The second receiving unit is configured to receive at least one target service data sent by the second terminal through the long connection which is in a connected state.

18. An electronic device, characterized in that, It includes a processor and a memory, the memory storing an application program, and the processor running the application program within the memory to perform the steps of the data transmission method according to any one of claims 1 to 16.

19. A computer program product comprising a computer program / instructions, characterized in that, When the computer program / instruction is executed by the processor, it implements the steps of the data transmission method according to any one of claims 1 to 16.

20. A computer-readable storage medium, characterized in that, The computer-readable storage medium stores a plurality of instructions adapted for loading by a processor to perform the steps of the data transmission method according to any one of claims 1 to 16.

Images