Data receiving method and apparatus, storage medium, and electronic device
Patent Information
- Application Number
- CN202311365015.3
- Authority / Receiving Office
- CN · China
- Patent Type
- Patents(China)
- Current Assignee / Owner
- Filing Date
- 2023-10-18
- Publication Date
- 2026-09-11
- Estimated Expiration
- 2043-10-18
AI Technical Summary
[0004]本发明实施例提供了一种数据接收方法、装置、存储介质及电子装置,以至少解决现有技术中单个同步连接并发存在多个业务请求时,需要等待前一个业务应答返回后才能处理下一个业务请求而导致的效率低的问题
[0015]This invention utilizes a single business thread to receive all response messages from the target device within a given time period, achieving thread reuse and eliminating the need to wait for the previous business response to return before processing the next business request. Furthermore, since a single thread is used for receiving response messages, business message receiving conflicts are avoided. Therefore, this invention solves the inefficiency problem in existing technologies where multiple business requests coexist on a single synchronous connection, requiring waiting for the previous business response to return before processing the next request, thus improving the efficiency of business request processing.
Smart Images

Figure CN117651071B_ABST
Abstract
Description
Technical Field
[0001] The present invention relates to the field of communications, and more specifically, to a data receiving method, apparatus, storage medium, and electronic device. Background Technology
[0002] In synchronous connections, message sending and receiving occur simultaneously; that is, after a request message is sent, a response message must be received before a response can be returned. In related technologies, when multiple business requests coexist on a single synchronous connection, it is necessary to wait for the response from the previous business request before processing the next, resulting in low efficiency in processing business requests.
[0003] There is currently no effective solution to the aforementioned problems in the relevant technologies. Summary of the Invention
[0004] This invention provides a data receiving method, apparatus, storage medium, and electronic device to at least solve the problem of low efficiency in the prior art when multiple service requests exist concurrently on a single synchronous connection, requiring waiting for the response of the previous service request before processing the next service request.
[0005] According to an embodiment of the present invention, a data receiving method is provided, comprising: when a first service thread is determined as a target service thread for receiving a response message from a target device in the current round of receiving processing, blocking other service threads, wherein the first service thread and the other service threads are both used to request the target device to provide a response message, and the other service threads include threads other than the first service thread established before the end of the current round of receiving processing for requesting the target device to provide a corresponding response message; before a preset receiving timeout period arrives, using the first service thread to receive the response message from the target device, wherein the preset receiving timeout period is the minimum value among the remaining timeout periods corresponding to a plurality of predetermined service threads, and the predetermined service thread is the first service thread. The business thread and the remaining business threads included in the other business threads that existed before the first business thread was determined as the target business thread, the minimum of the remaining timeout times for the first business thread and the remaining business threads, and the first business thread and the remaining business threads are each configured with a corresponding timeout time; if a response message is received from the target device before the preset reception timeout time expires, the blocked threads included in the remaining business threads are woken up, and the remaining business threads are instructed to match the corresponding response message from the response message received by the first business thread; or, if no response message is received from the target device after the preset reception timeout time expires, the blocked threads included in the remaining business threads are woken up.
[0006] In an exemplary embodiment, before waking up the blocked threads included in the remaining service threads, the method further includes: if the remaining timeout time corresponding to the second service thread is less than the preset reception timeout time, waking up the second service thread when the remaining timeout time corresponding to the second service thread is reached, wherein the second service thread is a thread included in the remaining service threads that is established after the first service thread is determined as the target service thread and before the end of the current round of reception processing, for requesting the target device to provide a response message.
[0007] In an exemplary embodiment, before a preset reception timeout period expires, the first service thread receives a response message from the target device, including: placing the received response message from the target device into a response message queue using the first service thread; instructing the remaining service threads to match corresponding response messages from the response messages received by the first service thread, including: instructing the remaining service threads to match corresponding response messages from the message queue.
[0008] In one exemplary embodiment, instructing the remaining service threads to match the corresponding response message from the message queue includes: instructing the remaining service threads to match the corresponding response message from the message queue based on an identifier pre-assigned for the request message sent by the remaining service threads, wherein in the response message queue, the response message is stored corresponding to a target identifier, and the target identifier stored corresponding to each response message is an identifier pre-generated for the request message corresponding to each response message.
[0009] In one exemplary embodiment, the method further includes: generating a corresponding identifier for the request message sent to the target device by the first service thread and any of the remaining service threads.
[0010] In an exemplary embodiment, after instructing the remaining service threads to match a corresponding response message from the response messages received by the first service thread, the method further includes: if a third service thread matches a corresponding response message from the response messages received by the first service thread, the third service thread provides feedback on the corresponding response message matched by the third service thread; if the third service thread does not match a corresponding response message from the response messages received by the first service thread, the third service thread determines its current remaining timeout and performs target processing corresponding to the current remaining timeout; wherein the third service thread is any one of the first service thread and the remaining service threads.
[0011] In an exemplary embodiment, performing the target processing corresponding to the current remaining timeout of the third service thread includes: if the current remaining timeout of the third service thread is greater than zero, reserving the third service thread for the next round of receiving processing; and if the current remaining timeout of the third service thread is equal to zero, feeding back a message indicating that the third service thread has not matched a corresponding response.
[0012] According to another embodiment of the present invention, a data receiving apparatus is provided, comprising: a blocking module, configured to block other service threads when a first service thread is determined to be a target service thread for receiving a response message from a target device in the current round of receiving processing, wherein the first service thread and the other service threads are both used to request the target device to provide a response message, and the other service threads include threads other than the first service thread established before the end of the current round of receiving processing for requesting the target device to provide a corresponding response message; and a receiving module, configured to receive the response message from the target device using the first service thread before a preset receiving timeout period arrives, wherein the preset receiving timeout period is the minimum value among the remaining timeout periods corresponding to a plurality of predetermined service threads, and the predetermined service threads are the... The first service thread and the remaining service threads include service threads that existed before the first service thread was determined as the target service thread. The first service thread and the remaining service threads each have their own minimum remaining timeout. The first service thread and the remaining service threads are each configured with their own timeout. The first wake-up module is used to wake up the blocked threads among the remaining service threads if a response message is received from the target device before the preset reception timeout expires, and instruct the remaining service threads to match the corresponding response message from the response message received by the first service thread. Alternatively, if no response message is received from the target device after the preset reception timeout expires, the blocked threads among the remaining service threads are also woken up.
[0013] According to yet another embodiment of the present invention, a computer-readable storage medium is also provided, wherein a computer program is stored therein, wherein the computer program is configured to perform the steps in any of the above method embodiments when executed.
[0014] According to yet another embodiment of the present invention, an electronic device is also provided, including a memory and a processor, wherein the memory stores a computer program and the processor is configured to run the computer program to perform the steps in any of the above method embodiments.
[0015] This invention utilizes a single business thread to receive all response messages from the target device within a given time period, achieving thread reuse and eliminating the need to wait for the previous business response to return before processing the next business request. Furthermore, since a single thread is used for receiving response messages, business message receiving conflicts are avoided. Therefore, this invention solves the inefficiency problem in existing technologies where multiple business requests coexist on a single synchronous connection, requiring waiting for the previous business response to return before processing the next request, thus improving the efficiency of business request processing. Attached Figure Description
[0016] Figure 1 This is a hardware structure block diagram of a mobile terminal for a data receiving method according to an embodiment of the present invention.
[0017] Figure 2 This is a flowchart of the data receiving method according to an embodiment of the present invention. Figure 1 ;
[0018] Figure 3 This is a flowchart of the data receiving method according to an embodiment of the present invention. Figure 2 ;
[0019] Figure 4 This is a structural block diagram of the data receiving device according to an embodiment of the present invention;
[0020] Figure 5 This is a system structure diagram of an embodiment of the present invention. Figure 1 ;
[0021] Figure 6 This is a system structure diagram of an embodiment of the present invention. Figure 2 . Detailed Implementation
[0022] The embodiments of the present invention will be described in detail below with reference to the accompanying drawings and examples.
[0023] It should be noted that the terms "first," "second," etc., in the specification, claims, and drawings of this invention are used to distinguish similar objects and are not necessarily used to describe a specific order or sequence.
[0024] The methods and embodiments provided in this application can be executed on a mobile terminal, computer terminal, or similar computing device. Taking running on a mobile terminal as an example, Figure 1 This is a hardware structure block diagram of a mobile terminal for a data receiving method according to an embodiment of the present invention. Figure 1 As shown, a mobile terminal may include one or more ( Figure 1Only one is shown in the diagram. A processor 102 (which may include, but is not limited to, a microprocessor MCU or a programmable logic device FPGA, etc.) and a memory 104 for storing data are also shown. The mobile terminal may further include a transmission device 106 for communication functions and an input / output device 108. Those skilled in the art will understand that... Figure 1 The structure shown is for illustrative purposes only and does not limit the structure of the mobile terminal described above. For example, the mobile terminal may also include components that are more... Figure 1 The more or fewer components shown, or having the same Figure 1 The different configurations shown.
[0025] The memory 104 can be used to store computer programs, such as application software programs and modules, like the computer program corresponding to the data receiving method in this embodiment of the invention. The processor 102 executes various functional applications and data processing by running the computer program stored in the memory 104, thus implementing the above-described method. The memory 104 may include high-speed random access memory and may also include non-volatile memory, such as one or more magnetic storage devices, flash memory, or other non-volatile solid-state memory. In some instances, the memory 104 may further include memory remotely located relative to the processor 102, and these remote memories can be connected to the mobile terminal via a network. Examples of such networks include, but are not limited to, the Internet, corporate intranets, local area networks, mobile communication networks, and combinations thereof.
[0026] The transmission device 106 is used to receive or send data via a network. Specific examples of the network described above may include a wireless network provided by the mobile terminal's communication provider. In one example, the transmission device 106 includes a Network Interface Controller (NIC), which can connect to other network devices via a base station to communicate with the Internet. In another example, the transmission device 106 may be a Radio Frequency (RF) module, used for wireless communication with the Internet.
[0027] This embodiment provides a data receiving method. Figure 2 This is a flowchart of a data receiving method according to an embodiment of the present invention, such as... Figure 2 As shown, the process includes the following steps:
[0028] Step S202: When the first service thread is determined to be the target service thread for receiving the response message from the target device in this round of receiving processing, the remaining service threads are blocked. The first service thread and the remaining service threads are both used to request the target device to provide a response message. The remaining service threads include threads other than the first service thread that were established before the end of this round of receiving processing to request the target device to provide the corresponding response message.
[0029] Step S204: Before the preset reception timeout period arrives, the first service thread receives the response message fed back by the target device. The preset reception timeout period is the minimum value among the remaining timeout periods corresponding to multiple predetermined service threads. The predetermined service threads are the service threads that existed before the first service thread was determined as the target service thread, which are included in the first service thread and the other service threads. The remaining timeout periods corresponding to the first service thread and the other service threads are the minimum values. The first service thread and the other service threads are each configured with a corresponding timeout period.
[0030] Step S206: If a response message is received from the target device before the preset reception timeout period expires, wake up the blocked threads included in the remaining service threads and instruct the remaining service threads to match the corresponding response message from the response message received by the first service thread; or, if no response message is received from the target device after the preset reception timeout period expires, wake up the blocked threads included in the remaining service threads.
[0031] In the above embodiment, in step S202, if a new service thread requesting a response message from the target device is established before the first service thread is determined as the target service thread, then when determining the target service thread, it can be determined from all existing service threads requesting a response message from the target device, including the newly established service thread. The method for determining the target service thread includes, but is not limited to, determining a randomly selected service thread as the target service thread, determining the service thread with the shortest remaining timeout as the target service thread, or determining the service thread with the highest score according to the scoring rules set by the technicians, etc. The remaining service threads include: service threads established before the first service thread is determined as the target service thread, and threads established after the first service thread is determined as the target service thread and before the end of the current round of receiving and processing for requesting a response message from the target device. The execution subjects of steps S202 and S206 include, but are not limited to, the first service thread and any of the remaining service threads. The methods for determining the remaining timeout for each business thread include, but are not limited to: assigning priorities to each business thread according to rules set by technical personnel, determining the remaining timeout based on the priorities of each business thread, determining the remaining timeout based on the order in which each business thread sends requests to the target device, and determining the remaining timeout for each business thread based on the type of request message sent by each business thread to the target device. The methods for blocking business threads include, but are not limited to: blocking the thread by calling the thread's sleep method, blocking the thread by calling the object's wait method, etc.
[0032] In the above steps, when the first business thread receives an acknowledgment message, it returns, ensuring the timeliness of message matching and further processing by the business thread corresponding to the acknowledgment message. If the first business thread does not receive an acknowledgment message, it wakes up any blocked threads among the remaining business threads, ensuring that the business threads that have not received the corresponding acknowledgment message can return when the preset reception timeout period is reached. By using a single business thread to receive all acknowledgment messages from the target device within a certain period, single-thread reuse is achieved, eliminating the need to wait for the previous business acknowledgment to return before processing the next business request. Furthermore, since a single thread is used to receive acknowledgment messages, business reception conflicts are avoided, solving the inefficiency problem in existing technologies where multiple business requests exist concurrently on a single synchronous connection, requiring waiting for the previous business acknowledgment to return before processing the next business request, thus improving business request processing efficiency.
[0033] In an optional embodiment, before waking up the blocked threads included in the remaining service threads, the method further includes: if the remaining timeout time corresponding to the second service thread is less than the preset reception timeout time, waking up the second service thread when the remaining timeout time corresponding to the second service thread is reached, wherein the second service thread is a thread included in the remaining service threads that is established after the first service thread is determined as the target service thread and before the end of the current round of reception processing to request the target device to provide a response message.
[0034] In the above embodiment, if the remaining timeout time corresponding to the second service thread is less than the preset reception timeout time, the second service thread is woken up when the remaining timeout time corresponding to the second service thread is zero. The second service thread then waits for the preset reception timeout time to arrive before matching the corresponding response message. In the above steps, by waking up threads in a blocked state, multiple service threads can perform message matching and processing simultaneously, improving system concurrency and efficiency. This reduces the waiting time of service threads, quickly processes response messages from the target device, and thus improves the system's response speed. The second service thread is the service thread that sends a request message to the target device after the start of the current reception round but before it ends. The criteria for determining the start of the current reception round include, but are not limited to: when the current reception thread has been selected, the current reception round is considered to have started; when the reception start flag is detected, the current reception round is considered to have started.
[0035] In an optional embodiment, before a preset reception timeout period expires, the first service thread receives the response message fed back by the target device, including: placing the received response message fed back by the target device into a response message queue using the first service thread; instructing the other service threads to match the corresponding response message from the response message received by the first service thread, including: instructing the other service threads to match the corresponding response message from the message queue.
[0036] In the above embodiments, the storage methods for the response messages received by the first service thread from the target device include, but are not limited to: using blocking to store the response messages, using a thread-safe collection class to store the response messages, using a message queue to store the response messages, and storing the response messages in a database or cache.
[0037] In the above steps, the other business threads are instructed to match the corresponding response messages from the response messages received by the first business thread. Each business thread only needs to focus on its own response message and does not need to focus on the response messages of other business threads, which can reduce the complexity of the system.
[0038] In an optional embodiment, instructing the remaining service threads to match the corresponding response message from the message queue includes: instructing the remaining service threads to match the corresponding response message from the message queue based on an identifier pre-assigned for the request message sent by the remaining service threads, wherein in the response message queue, the response message is stored in correspondence with a target identifier, and the target identifier stored in correspondence with each response message is an identifier pre-generated for the request message corresponding to each response message.
[0039] In the above embodiments, the identification is generated in ways including but not limited to: generating an identification according to rules established by technical personnel, combined with the time when the business thread sends the request and its own attributes. The entity executing the identification generation includes, but is not limited to: each business thread executing the generation itself, a randomly selected business thread executing the generation, or a business thread selected from all business threads according to rules established by technical personnel executing the generation. The methods for storing the corresponding response message and target identification include, but are not limited to: using a Map data structure, storing the target identification as the key and the response message as the value, for example, using HashMap or ConcurrentHashMap; or storing the target identification and response message in a database, such as a relational database (e.g., MySQL, Oracle), etc.
[0040] In an optional embodiment, the method further includes: generating a corresponding identifier for the request message sent to the target device by the first service thread and any of the remaining service threads.
[0041] In the above embodiments, the correspondence between the identifier and the request message is implemented in ways including but not limited to the following:
[0042] 1. Achieve this through a unique identifier: Each request has a unique identifier, which can be a string, number, or other unique identifier. When sending a request, the identifier is sent along with the request to the server. Upon receiving the request, the server can identify and process the corresponding request based on the identifier.
[0043] 2. Implemented through a request-response pattern: In a request-response pattern, each request has a corresponding response. When sending a request, the request and response can be bound together, for example, using a data structure or object that contains the request and response. After receiving the request, the server processes it and generates the corresponding response, then sends the response back to the client. The client uses the response to identify and process the corresponding request.
[0044] 3. Implementation via Request ID: When sending a request, a unique request ID can be assigned to each request. Upon receiving the request, the server binds the request ID to the request and includes the request ID in the response. Upon receiving the response, the client identifies and processes the corresponding request based on the request ID.
[0045] 4. Implemented by setting a context object: A context object can be used to store the association information between requests and responses. When a request is sent, the request information is stored in the context object, and the context object is associated with the request. After receiving the request, the server can retrieve the request information from the context object, generate the corresponding response, and store the response information in the context object. After receiving the response, the client identifies and processes the corresponding request based on the context object.
[0046] In an optional embodiment, after instructing the remaining service threads to match a corresponding response message from the response messages received by the first service thread, the method further includes: if the third service thread matches a corresponding response message from the response messages received by the first service thread, the third service thread provides feedback on the corresponding response message matched by the third service thread; if the third service thread does not match a corresponding response message from the response messages received by the first service thread, the third service thread determines its current remaining timeout and performs target processing corresponding to the current remaining timeout; wherein, the third service thread is any one of the first service thread and the remaining service threads.
[0047] In the above steps, if the third service thread receives a corresponding response message from the target device, then this service thread completes its task. The processing methods for a completed service thread include, but are not limited to: releasing the service thread that has completed its task, or waiting for a service thread to be used for the next round of requesting a response message from the target device, etc. The ways in which the target device sends a response message include, but are not limited to, the following:
[0048] 1. Pass the response message to the business thread through a callback function.
[0049] 2. The target device writes the response message into a pipe or buffer, and the business thread can read the response message from the pipe or buffer.
[0050] 3. The target device writes the response message into the shared memory, and the business thread can read the response message from the shared memory.
[0051] 4. Callback Function: The target device passes the response message to the business thread through a callback function. The business thread provides a callback function, which the target device calls after processing the request, passing the response message as a parameter.
[0052] In an optional embodiment, performing the target processing corresponding to the current remaining timeout of the third service thread includes: if the current remaining timeout of the third service thread is greater than zero, reserving the third service thread for the next round of receiving processing; if the current remaining timeout of the third service thread is equal to zero, feeding back a message indicating that the third service thread has not matched a corresponding response.
[0053] In the above steps, by determining the remaining timeout of the third business thread and executing the target processing for unmatched response messages, the system can ensure that it can respond to the next step in a timely manner. Feedback to the third business thread that did not find a matching response message ensures the integrity of the request message.
[0054] The following describes in general terms how the present invention receives data, with reference to specific embodiments:
[0055] Figure 3 This is a flowchart of a data receiving method according to a specific embodiment of the present invention, including:
[0056] S302, each service thread sends a request message to the target device;
[0057] S304 generates a unique message identifier for each business thread, used to match the corresponding response;
[0058] S306, Determine whether the current round of reception has started; if it has started, proceed to step S318; if it has not started, execute step S308.
[0059] S308, determine whether it is selected as the receiving thread for this round; if it is not selected, jump to step S322; if it is selected, execute step S310.
[0060] S310, This round of reception begins, and the minimum remaining reception time for all service threads is used as the timeout for this round of reception.
[0061] S312, determine whether a message has been received within the timeout period; if no message has been received, proceed to step S316; if a message has been received, execute step S314.
[0062] S314, parse the message and enqueue it;
[0063] S316, This round of reception has ended, wake up other business threads;
[0064] S318, determine whether the preset receiving timeout of the current business thread is greater than the receiving timeout of this round; if it is greater, proceed to step S322; if it is not greater, proceed to step S320.
[0065] S320: The current business thread is blocked for a preset receive timeout period and will be automatically woken up after the timeout.
[0066] S322, the thread is blocked indefinitely;
[0067] S324, the thread is awakened;
[0068] S326, Determine whether the corresponding response message has been obtained from the queue based on the message identifier; if it has been obtained, the process ends; if it has not been obtained, proceed to step S328.
[0069] S328, determine the remaining reception time of the calculation business thread and determine whether the reception has timed out; if it has timed out, end; if it has not timed out, jump to step S308.
[0070] In step S302, each service thread sends a request message and waits for the corresponding response message from the target device.
[0071] In step S304, the unique message identifier is generated in ways including but not limited to: generating a unique message identifier according to rules established by technical personnel, combining the time when the business thread sends the request and its own attributes. The executing entity that generates the unique message identifier includes, but is not limited to: execution by each business thread itself, execution by a randomly selected business thread, or execution by a business thread selected from all business threads according to rules established by technical personnel.
[0072] In step S306, when a new service thread sends a request message to the target device and waits for a response, it is determined whether the current round of reception has started. The method for determining whether the current round of reception has started includes, but is not limited to: if the current round of reception thread (corresponding to the aforementioned first service thread) has been selected, the current round of reception is considered to have started. If the current round of reception has not started, a new service thread may be identified as the current round of reception thread.
[0073] In step S310, all service threads are the aforementioned service threads that have the opportunity to be identified as receiving threads in this round. Among all service threads, service threads that have started after the start of this round of receiving are not included.
[0074] In step S314, the receiving thread in this round parses all the response messages received from the target device and puts them into the message queue according to certain rules. The methods for putting messages into the message queue include, but are not limited to: putting messages into the queue according to the time they were sent, putting messages into the queue according to their own attributes, putting messages into the queue according to rules set by technical personnel, and putting messages into the queue according to the order in which they were received.
[0075] In step S316, the other service threads refer to all service threads other than the receiving thread in this round.
[0076] In step S318, when the current service thread is new and sends a request to the target device, the new service thread that has started receiving in this round.
[0077] Through the above description of the embodiments, those skilled in the art can clearly understand that the methods according to the above embodiments can be implemented by means of software plus necessary general-purpose hardware platforms. Of course, they can also be implemented by hardware, but in many cases the former is a better implementation method. Based on this understanding, the technical solution of the present invention, in essence, or the part that contributes to the prior art, can be embodied in the form of a software product. This computer software product is stored in a storage medium (such as ROM / RAM, magnetic disk, optical disk) and includes several instructions to cause a terminal device (which may be a mobile phone, computer, server, or network device, etc.) to execute the methods described in the various embodiments of the present invention.
[0078] This embodiment also provides a data receiving device for implementing the above embodiments and preferred embodiments; details already described will not be repeated. As used below, the term "module" can refer to a combination of software and / or hardware that performs a predetermined function. Although the device described in the following embodiments is preferably implemented in software, hardware implementation, or a combination of software and hardware, is also possible and contemplated.
[0079] Figure 4 This is a structural block diagram of a data receiving device according to an embodiment of the present invention, such as... Figure 4As shown, the device includes: a blocking module 42, used to block other service threads when a first service thread is determined to be the target service thread for receiving a response message from the target device in the current round of receiving processing, wherein both the first service thread and the other service threads are used to request the target device to provide a response message, and the other service threads include threads other than the first service thread established before the end of the current round of receiving processing for requesting the target device to provide a corresponding response message; and a receiving module 44, used to receive the response message from the target device using the first service thread before a preset receiving timeout period arrives, wherein the preset receiving timeout period is the minimum value among the remaining timeout periods corresponding to a plurality of predetermined service threads, and the predetermined service threads are the first service thread and the other service thread. The remaining service threads include service threads that existed before the first service thread was determined as the target service thread. The remaining timeout time for both the first service thread and the remaining service threads is the minimum value. Both the first service thread and the remaining service threads are configured with corresponding timeout times. The first wake-up module 46 is used to wake up the blocked threads among the remaining service threads if a response message is received from the target device before the preset reception timeout time expires, and instruct the remaining service threads to match the corresponding response message from the response message received by the first service thread. Alternatively, if no response message is received from the target device after the preset reception timeout time expires, the blocked threads among the remaining service threads are woken up.
[0080] In an optional embodiment, the device further includes: a second wake-up module, configured to wake up the second service thread when the remaining timeout time corresponding to the second service thread is less than the preset reception timeout time, wherein the second service thread is a thread included among the remaining service threads, established after the first service thread is determined as the target service thread and before the end of the current round of reception processing, for requesting the target device to provide a response message.
[0081] In an optional embodiment, the receiving module 44 includes a processing unit, configured to use the first service thread to place the received response message fed back by the target device into a response message queue.
[0082] In an optional embodiment, the first wake-up module 46 includes: an indication unit, used to instruct the remaining business threads to match the corresponding response message from the message queue.
[0083] In an optional embodiment, the indication unit includes: an indication subunit, configured to instruct the remaining service threads to match corresponding response messages from the message queue based on an identifier pre-assigned for request messages sent by the remaining service threads, wherein in the response message queue, the response messages are stored corresponding to target identifiers, and the target identifier stored corresponding to each response message is an identifier pre-generated for the request message corresponding to each response message.
[0084] In an optional embodiment, the apparatus further includes: a generation module, configured to generate a corresponding identifier for request messages sent to the target device by the first business thread and any of the remaining business threads.
[0085] In an optional embodiment, the first business thread and the remaining business threads include a third business thread, which includes: a feedback module, configured to, when a corresponding response message is matched in the response messages received from the first business thread, feed back the corresponding response message matched by the third business thread; and a processing module, configured to, when no corresponding response message is matched in the response messages received from the first business thread, determine the current remaining timeout of the third business thread and perform target processing corresponding to the current remaining timeout of the third business thread; wherein, the third business thread is any business thread included in the first business thread and the remaining business threads.
[0086] In an optional embodiment, the processing module includes: a retention unit, configured to retain the third service thread for the next round of receiving processing if the remaining timeout of the third service thread is greater than zero; and a feedback unit, configured to provide feedback that the third service thread has not matched a corresponding response message if the remaining timeout of the third service thread is equal to zero.
[0087] It should be noted that the above modules can be implemented by software or hardware. For the latter, they can be implemented in the following ways, but are not limited to: all the above modules are located in the same processor; or, the above modules are located in different processors in any combination.
[0088] Figure 5 This is a system composition diagram according to an embodiment of the present invention. Figure 5 This illustrates the system composition of a single synchronous connection when a client controls a device. The synchronous connection includes, but is not limited to, TCP connections and MQTT connections.
[0089] Figure 6 This is a system composition diagram according to an embodiment of the present invention. Figure 6This illustration depicts a system consisting of multiple synchronous connections when a client simultaneously controls multiple devices. The devices include, but are not limited to, terminal devices with communication capabilities, and the client includes, but is not limited to, user access terminals such as mobile apps. A client can control one or more devices simultaneously. Before controlling a device, a synchronous connection is established with each device. Business threads use these synchronous connections to send business request messages and receive corresponding business response messages via business calls (such as API calls). These business calls are synchronous calls, returning only after receiving a response message or after a timeout. Multiple concurrent business calls are allowed on this synchronous connection, each driven by a business thread. Business calls include, for example, initializing an account, obtaining device information, and obtaining encoding configurations. Furthermore, the methods in this proposal include, but are not limited to, those applied to the synchronous connection module.
[0090] Embodiments of the present invention also provide a computer-readable storage medium storing a computer program, wherein the computer program is configured to perform the steps in any of the above method embodiments when executed.
[0091] In one exemplary embodiment, the aforementioned computer-readable storage medium may include, but is not limited to, various media capable of storing computer programs, such as a USB flash drive, read-only memory (ROM), random access memory (RAM), portable hard drive, magnetic disk, or optical disk.
[0092] Embodiments of the present invention also provide an electronic device including a memory and a processor, the memory storing a computer program and the processor being configured to run the computer program to perform the steps in any of the above method embodiments.
[0093] In one exemplary embodiment, the electronic device may further include a transmission device and an input / output device, wherein the transmission device is connected to the processor and the input / output device is connected to the processor.
[0094] Specific examples in this embodiment can be found in the examples described in the above embodiments and exemplary implementations, and will not be repeated here.
[0095] It is obvious to those skilled in the art that the modules or steps of the present invention described above can be implemented using general-purpose computing devices. They can be centralized on a single computing device or distributed across a network of multiple computing devices. They can be implemented using computer-executable program code, and thus can be stored in a storage device for execution by a computing device. In some cases, the steps shown or described can be performed in a different order than those described herein, or they can be fabricated as separate integrated circuit modules, or multiple modules or steps can be fabricated as a single integrated circuit module. Thus, the present invention is not limited to any particular combination of hardware and software.
[0096] The above description is merely a preferred embodiment of the present invention and is not intended to limit the invention. Various modifications and variations can be made to the invention by those skilled in the art. Any modifications, equivalent substitutions, or improvements made within the principles of the present invention should be included within the scope of protection of the present invention.
Claims
1. A data receiving method, characterized in that, include: When the first service thread is determined to be the target service thread for receiving the response message from the target device in this round of receiving processing, the remaining service threads are blocked. The first service thread and the remaining service threads are both used to request the target device to send a response message, and the remaining service threads include threads other than the first service thread that were established before the end of the current round of receiving processing to request the target device to send a corresponding response message. Before the preset reception timeout period arrives, the first service thread receives the response message from the target device. The preset reception timeout period is the minimum value among the remaining timeout periods corresponding to multiple predetermined service threads. The predetermined service threads are service threads that existed before the first service thread was determined as the target service thread, which are included in the first service thread and the other service threads. The minimum value among the remaining timeout periods corresponding to the first service thread and the other service threads, and the first service thread and the other service threads are each configured with a corresponding timeout period. If a response message is received from the target device before the preset reception timeout period expires, the thread in the blocked state among the remaining service threads is woken up, and the remaining service threads are instructed to match the corresponding response message from the response message received by the first service thread. Alternatively, if no response message is received from the target device after the preset reception timeout period expires, the thread in the blocked state among the remaining service threads is woken up.
2. The method according to claim 1, characterized in that, Before waking up the blocked threads among the remaining business threads, the method further includes: If the remaining timeout time corresponding to the second service thread is less than the preset reception timeout time, the second service thread is woken up when the remaining timeout time corresponding to the second service thread is reached. The second service thread is a thread included among the other service threads, which is established after the first service thread is determined as the target service thread and before the end of the current reception processing, to request the target device to provide a response message.
3. The method according to claim 1, characterized in that, Before the preset reception timeout period expires, the first service thread is used to receive the response message fed back by the target device, including: using the first service thread to put the received response message fed back by the target device into the response message queue; Instructing the remaining service threads to match the corresponding response message from the response message received by the first service thread includes: instructing the remaining service threads to match the corresponding response message from the message queue.
4. The method according to claim 3, characterized in that, Instructing the remaining business threads to match the corresponding response message from the message queue includes: The remaining business threads are instructed to match corresponding response messages from the message queue based on identifiers pre-assigned to request messages sent by the remaining business threads. In the response message queue, each response message is stored in relation to a target identifier, and the target identifier stored in relation to each response message is an identifier pre-generated for the request message corresponding to each response message.
5. The method according to claim 4, characterized in that, The method further includes: Generate a corresponding identifier for the request message sent to the target device by the first business thread and any of the remaining business threads.
6. The method according to claim 1, characterized in that, After instructing the remaining service threads to match the corresponding response message from the response messages received by the first service thread, the method further includes: If the third business thread matches the corresponding response message in the response message received from the first business thread, the third business thread shall return the corresponding response message matched by the third business thread. If the third business thread does not find a corresponding response message in the response message received from the first business thread, it determines the remaining timeout of the third business thread and executes the target processing corresponding to the remaining timeout of the third business thread; wherein, the third business thread is any business thread included in the first business thread and the remaining business threads.
7. The method according to claim 6, characterized in that, Executing the target processing corresponding to the current remaining timeout of the third business thread includes: If the remaining timeout of the third service thread is greater than zero, the third service thread will be reserved for the next round of receiving and processing. If the remaining timeout of the third business thread is zero, a message indicating that the third business thread has not found a matching response will be sent.
8. A data receiving device, characterized in that, include: A blocking module is used to block other service threads when the first service thread is determined to be the target service thread for receiving the response message from the target device in the current round of receiving processing. The first service thread and the other service threads are both used to request the target device to send a response message, and the other service threads include threads other than the first service thread that were established before the end of the current round of receiving processing to request the target device to send a corresponding response message. A receiving module is used to receive a response message from the target device using the first service thread before a preset receiving timeout period arrives. The preset receiving timeout period is the minimum value among the remaining timeout periods corresponding to multiple predetermined service threads. The predetermined service threads are service threads that existed before the first service thread was determined as the target service thread, which are included among the first service thread and the other service threads. The minimum value among the remaining timeout periods corresponding to the first service thread and the other service threads is also included. The first service thread and the other service threads are each configured with a corresponding timeout period. The first wake-up module is configured to wake up the blocked threads among the remaining service threads if a response message is received from the target device before the preset reception timeout period expires, and instruct the remaining service threads to match the corresponding response message from the response message received by the first service thread; or, if no response message is received from the target device after the preset reception timeout period expires, wake up the blocked threads among the remaining service threads.
9. A computer-readable storage medium, characterized in that, The computer-readable storage medium stores a computer program, wherein the computer program, when executed by a processor, implements the steps of the method described in any one of claims 1 to 7.
10. An electronic device comprising a memory, a processor, and a computer program stored in the memory and executable on the processor, characterized in that, When the processor executes the computer program, it implements the steps of the method described in any one of claims 1 to 7.
Citation Information
Patent Citations
Information processing method and device, server cluster, electronic equipment and medium
CN116743754A
A distributed message invoking method and device
WO2009129732A1