CN110034857B - Request sending method and device and electronic equipment - Google Patents
Request sending method and device and electronic equipment Download PDFInfo
- Publication number
- CN110034857B CN110034857B CN201910316975.8A CN201910316975A CN110034857B CN 110034857 B CN110034857 B CN 110034857B CN 201910316975 A CN201910316975 A CN 201910316975A CN 110034857 B CN110034857 B CN 110034857B
- Authority
- CN
- China
- Prior art keywords
- request
- preset
- target request
- resending
- server
- Prior art date
- Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
- Active
Links
Images
Classifications
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L1/00—Arrangements for detecting or preventing errors in the information received
- H04L1/08—Arrangements for detecting or preventing errors in the information received by repeating transmission, e.g. Verdan system
Landscapes
- Engineering & Computer Science (AREA)
- Computer Networks & Wireless Communication (AREA)
- Signal Processing (AREA)
- Computer And Data Communications (AREA)
- Information Transfer Between Computers (AREA)
Abstract
The application provides a request sending method, a request sending device and electronic equipment, relates to the technical field of network communication, and can solve the technical problem that a server fails to receive a request sent by a terminal. The method comprises the following steps: receiving error information sent by a server, wherein the error information is used for indicating that a target request is received wrongly, and the target request is a network request sent to the server by the terminal; judging whether the target request meets a preset resending condition or not, and judging whether the number of times of resending permission of the target request is greater than the preset number of times or not, wherein the preset resending condition is used for representing a preset request type and preset request content of the target request; and if the target request meets a preset resending condition and the number of times of resending permission of the target request is greater than the preset number of times, resending the target request to the server after a preset delay.
Description
Technical Field
The present application relates to the field of network communication technologies, and in particular, to a method and an apparatus for requesting transmission, and an electronic device.
Background
There are many ways of interaction between the server and the terminal, and generally, the terminal at the front end sends a network request to the server at the back end according to the user input. There are many types of network requests, including: a Fetch request (a network request using asynchronous characteristics of a request), a HyperText Transfer Protocol (HTTP) request, a Transmission Control Protocol (TCP) request, and the like.
The server can execute the response action after successfully receiving the network request sent by the terminal. For example, the terminal sends a web page request to the server, and when the server successfully receives the web page request, the server sends a response that the network request is successfully received to the terminal, so that the terminal determines that the request is successfully sent, and the terminal waits for the execution result of the server. Meanwhile, the server executes corresponding action according to the webpage request and sends the address corresponding to the webpage requested by the terminal to the terminal.
However, in a large and medium-sized website, problems such as instability of the server due to network fluctuations often occur, and reception of a request transmitted from the server to the terminal fails.
Disclosure of Invention
The application aims to provide a request sending method, a request sending device and electronic equipment, so as to solve the technical problem that the request sent by a server to a terminal fails to be received.
In a first aspect, an embodiment of the present application provides a method for requesting transmission, which is applied to a terminal, and includes:
receiving error information sent by a server, wherein the error information is used for indicating that a target request is received wrongly, and the target request is a network request sent to the server by the terminal;
judging whether the target request meets a preset resending condition or not, and judging whether the number of times of resending permission of the target request is greater than the preset number of times or not, wherein the preset resending condition is used for representing a preset request type and preset request content of the target request;
and if the target request meets a preset resending condition and the number of times of resending permission of the target request is greater than the preset number of times, resending the target request to the server after a preset delay.
In a second aspect, an embodiment of the present application further provides an apparatus for requesting transmission, including:
the receiving module is used for receiving error information sent by a server, wherein the error information is used for indicating that a target request is received wrongly, and the target request is a network request sent to the server by the terminal;
the judging module is used for judging whether the target request meets a preset resending condition or not and judging whether the number of times of resending permission of the target request is greater than the preset number of times or not, wherein the preset resending condition comprises a preset request type and preset request content;
and the sending module is used for sending the target request to the server again after a preset time delay if the target request meets a preset resending condition and the number of times of allowed resending of the target request is greater than the preset number of times.
In a third aspect, an embodiment of the present application further provides an electronic device, which includes a memory and a processor, where the memory stores a computer program that is executable on the processor, and the processor implements the steps of the method according to the first aspect when executing the computer program.
In a fourth aspect, embodiments of the present application further provide a computer-readable medium having non-volatile program code executable by a processor, the program code causing the processor to perform the method according to the first aspect.
In the scheme, when the server fails to receive the target request sent by the terminal, the terminal receives error information sent by the server, then judges whether the target request meets the preset resending condition or not and judges whether the number of times of allowing resending of the target request is greater than the preset number of times or not, and resends the target request to the server when the target request meets the preset resending condition and the number of times of allowing resending is greater than the preset number of times. Therefore, when the server fails to receive the target request, the terminal can firstly make a series of judgments so as to judge whether the target request needs to be retransmitted or not. The target request is judged whether to accord with the preset resending condition or not, so that the target request which does not need to be resent is avoided being resent again, and the target request is also avoided being resent for infinite times due to the fact that whether the number of times of resending is judged to be larger than the preset number of times, so that the unnecessary data processing process is saved. And then after the preset time delay, the target request is sent to the server again, so that the situations of overlapping sending of the target request in a short time and the like are avoided, unnecessary data processing processes are reduced, the working efficiency of sending the target request is improved, the server is ensured to successfully receive the received target request, and the target request resending efficiency is also improved.
Drawings
In order to more clearly illustrate the detailed description of the present application or the technical solutions in the prior art, the drawings needed to be used in the detailed description of the present application or the prior art description will be briefly introduced below, and it is obvious that the drawings in the following description are some embodiments of the present application, and other drawings can be obtained by those skilled in the art without creative efforts.
Fig. 1 is a flowchart illustrating a method for requesting transmission according to an embodiment of the present application;
fig. 2 is a flowchart illustrating a method for automatic resending of a Fetch request failure according to an embodiment of the present application;
fig. 3 is a schematic structural diagram illustrating an apparatus for requesting transmission according to an embodiment of the present application;
fig. 4 shows a schematic structural diagram of an electronic device provided in an embodiment of the present application.
Detailed Description
The technical solutions of the present invention will be described clearly and completely with reference to the following embodiments, and it should be understood that the described embodiments are some, but not all, embodiments of the present invention. All other embodiments, which can be derived by a person skilled in the art from the embodiments given herein without making any creative effort, shall fall within the protection scope of the present invention.
Features and exemplary embodiments of various aspects of the present invention will be described in detail below. In the following detailed description, numerous specific details are set forth in order to provide a thorough understanding of the present invention. It will be apparent, however, to one skilled in the art that the present invention may be practiced without some of these specific details. The following description of the embodiments is merely intended to provide a better understanding of the present invention by illustrating examples of the present invention. The present invention is in no way limited to any specific configuration and algorithm set forth below, but rather covers any modification, replacement or improvement of elements, components or algorithms without departing from the spirit of the invention. In the drawings and the following description, well-known structures and techniques are not shown in order to avoid unnecessarily obscuring the present invention.
It should be noted that the embodiments and features of the embodiments in the present application may be combined with each other without conflict. The present application will be described in detail below with reference to the embodiments with reference to the attached drawings.
Furthermore, the terms "comprising" and "having" and any variations thereof as referred to in the description of the invention are intended to cover non-exclusive inclusions. For example, a process, method, system, article, or apparatus that comprises a list of steps or elements is not limited to only those steps or elements but may alternatively include other steps or elements not expressly listed or inherent to such process, method, article, or apparatus.
At present, in large and medium-sized websites, problems such as network fluctuation and server instability are often encountered, so that a request initiated by a front-end terminal fails. Based on this, the method, the device and the electronic device for request sending provided by the embodiments of the present application can solve the technical problem that the request sent by the server to the terminal fails to be received in the prior art.
For the convenience of understanding the present embodiment, a method, an apparatus, and an electronic device for requesting transmission disclosed in the embodiments of the present application will be described in detail first.
A method for requesting transmission provided in an embodiment of the present application is applied to a terminal, and as shown in fig. 1, the method includes:
s11: and receiving error information sent by the server, wherein the error information is used for indicating that a target request is received incorrectly, and the target request is a network request sent by the terminal to the server.
If the receiving process of the network request sent by the terminal by the server fails, the server sends error information to the terminal, wherein the error information is used for indicating that the receiving process of the target request by the server is wrong.
S12: and judging whether the target request meets a preset resending condition or not, and judging whether the number of times of resending permission of the target request is greater than the preset number of times or not, wherein the preset resending condition is used for representing the preset request type and the preset request content of the target request. If the target request meets the predetermined resending condition and the number of times of resending the target request is greater than the predetermined number of times, step S13 is performed.
In this embodiment, the number of times of retransmission permission refers to the number of times of retransmission permission of the terminal to the server. The preset resending condition may include a preset request type of the target request and a limitation condition of the target request such as a preset request content.
In this step, when receiving the error message sent by the server, the terminal determines whether the target request conforms to the preset request type and the preset request content, and determines whether the number of times of allowing the target request to be resent is greater than the preset number of times. If the target request is consistent with the preset request type, the target request is also consistent with the preset request content, and the number of times of allowed resending of the target request is greater than the preset number of times, then step S13 is performed.
S13: and after a preset time delay, the target request is sent to the server again.
And if the target request is consistent with the preset request type, the target request is also consistent with the preset request content, and the number of times of allowing the target request to be retransmitted is greater than the preset number of times, the terminal retransmits the target request to the server after the preset delay, so that automatic retransmission after the request transmission fails is realized. In addition, in the step, after the preset time delay, the target request is sent to the server again, so that the situations of overlapping sending of the target request in a short time and the like are avoided, and the working efficiency of sending the target request is improved.
Therefore, by the method for requesting to send, the request can be automatically sent again under the condition of failed sending, a user does not need to manually retry the request, and the user experience is improved. Moreover, in the embodiment, the terminal also judges whether the target request meets the preset resending condition, so that the target request which does not need to be resent is avoided being resent again, and the terminal also judges whether the number of times of allowing resending is greater than the preset number of times, so that the target request is also avoided being resent for infinite number of times, unnecessary data processing procedures are saved, and the target request is ensured to be successfully received by the server under the condition of improving the resending efficiency of the target request.
In order to flexibly configure the re-sent execution parameters, before the target request is sent to the server for the first time, the method further comprises the following steps:
and acquiring a request parameter in the target request, and combining the request parameter and a retry parameter to obtain a re-request parameter, wherein the retry parameter comprises the number of times of allowed re-sending of the target request, a preset re-sending condition and a preset time delay.
The type of target request may be many, such as a Fetch request, an HTTP request, a TCP request, and the like. The present embodiment will be described by taking an example in which the target request is a Fetch request. The Fetch is an Application Programming Interface (API) with a higher encapsulation degree, and uses a plan, which is a solution of asynchronous Programming, and the Fetch request uses the asynchronous characteristic of the request to perform a network request. The method of terminal and server interaction is gradually replaced by Fetch at present. Fetch supports Promise and can be easily used by other technologies, such as acting as a proxy Service Worker between an Internet application and a browser.
In this embodiment, before sending the Fetch request to the server for the first time, the request parameter of the native Fetch request to be sent is obtained, the retry parameter is set according to the user input, and the retry parameter is combined with the request parameter of the native Fetch request. For example, as shown in fig. 2, a Fetch request native parameter to be sent is acquired, and a retry parameter is set and combined with the Fetch request native parameter.
The retry parameters may include: fetch request retry number; the Fetch request retries once every several times, and the unit is second; a Fetch request retry condition judgment function; the condition function condition defaults to a function returning true; and (4) judging whether to retry the error data error returned by the failed request according to the incoming error, wherein a return true indicates retry, and otherwise, the retry is not carried out.
As shown in fig. 2, after this step, the method may further include: initializing a Promise task queue, and adding a Fetch request, a do not process function and a retry interceptor to the Promise task queue in sequence, wherein the retry interceptor is a function representing a function for executing a retry judgment process. Specifically, the method comprises the following steps: firstly, creating a null array as a premium Task, wherein the premium Task is a queue and meets the first-in first-out characteristic of the queue; acquiring a Fetch request, and adding the Fetch request into a premium Task queue; setting an unprocessed function, wherein the unprocessed function is executed only under the condition that the Fetch request is successful, and the unprocessed function directly returns a response result without any other processing; then adding the unprocessed function into a premium Task queue; setting a function for executing a retry judgment process, namely a retry interceptor function, wherein the retry interceptor function is executed after the Fetch request fails, and the retry interceptor function determines whether the Fetch request can be retransmitted or not; a retry interceptor function is added to the Promise task queue.
Thus, the Promise task queue contents include: a Fetch request, a not-processed function when the Fetch request succeeds, and a retry interceptor processing function. Therefore, the method realizes that the Fetch request is intercepted and processed by the retry interceptor processing function when failing to judge whether the Fetch request is retransmitted or not.
As shown in fig. 2, the commit task queue is then started to wait for the success of the Fetch request. Specifically, the method comprises the following steps: traversing the remise task queue, taking out two tasks each time as a batch, respectively corresponding to the on fulilled and the on Rejected, if the execution of the on fulilled of the previous batch of tasks is successful, the on fulilled of the next batch of tasks is captured, if the execution is failed, the on Rejected of the next batch of tasks is captured, thus achieving the purpose of request interception. The Fetch request is executed for the first time, when the Fetch request is successful, an unprocessed function, namely on Fulfilled, is executed, and the function directly returns a response result to complete the request; when the Fetch request is in error, a retry interceptor handling function, i.e., on Rejected, is executed.
Therefore, through the process of setting parameters and the like, various retry parameters can be customized, including parameters such as the number of allowed resending times of the target request, the preset resending condition, the preset time delay and the like, so that the retry parameters such as the retry times, the single retry delay time, the retry condition and the like can be flexibly configured, and the method for requesting to send can be flexibly applied.
In order to facilitate the determination of the speed of the process, the step of determining whether the target request meets the preset retransmission condition and determining whether the number of times of the target request allowed to be retransmitted is greater than the preset number of times (i.e., step S12) may include the steps of:
and acquiring the number of times of retransmission permission and a preset retransmission condition from the retransmission request parameter, judging whether the target request meets the preset retransmission condition, and judging whether the number of times of retransmission permission is greater than the preset number.
The preset number of times may be a plurality of integers such as 0, 1, 2, 3, 4, or 5. This embodiment will be described by taking the preset number of times as 1. For example, as shown in fig. 2, if the Fetch request fails to be sent, the terminal passes the error information returned by the server to the retry interceptor processing function, and determines whether the number of retries is greater than 1 and whether the retry condition is satisfied.
Specifically, the terminal acquires error information returned by the server as error, then acquires a retry count function from the retry request parameter, acquires a retry condition judgment function as a condition function from the retry request parameter, and then performs a judgment process according to the retry count function and the condition function.
Therefore, the terminal can directly acquire the number of times of allowed retransmission and the preset retransmission condition from the previously set retransmission request parameter, so that the terminal can rapidly enter the subsequent judgment process according to the number of times of allowed retransmission and the preset retransmission condition, and the working efficiency of the judgment process is improved.
In order to avoid resending the target request an unlimited number of times and to avoid resending the target request that does not need to be resent again, after the step of determining whether the target request meets the preset resending condition and determining whether the number of allowed resending times of the target request is greater than the preset number (i.e., step S11), the following steps may be further included:
if the target request does not accord with the preset resending condition, or the number of times of allowed resending of the target request is less than or equal to the preset number of times, or the target request does not accord with the preset resending condition and the number of times of allowed resending of the target request is less than or equal to the preset number of times, the sending process of the target request is finished. For example, if the retry count is less than 1, indicating that the retry count is used up, the request will be ended directly; if the condition execution result does not return true, it indicates that the target request does not conform to the condition, i.e. the resending condition is preset, and the request is also directly ended.
Therefore, the resending condition is not satisfied and the number of times of resending is allowed to be insufficient, and at least one of these two cases occurs, so that the sending process of the target request is ended, that is, the target request is not resent any more. Therefore, the target request which does not need to be retransmitted again is prevented from being retransmitted again, the situations of overlapping transmission of the target request in a short time and the like are also prevented, unnecessary data processing processes are reduced, the working efficiency of transmitting the target request is improved, and the efficiency of retransmitting the target request is improved.
In order to enable the resending process to be performed in order, the resending the target request to the server after the preset delay (i.e., step S13) may include the following steps:
and acquiring a preset time delay from the re-request parameters, and re-sending the target request to the server after the preset time delay. For example, as shown in fig. 2, if the retry count is greater than or equal to 1, it indicates that the number of retries is not exhausted; if the condition execution result returns true, it indicates that the target request conforms to the condition. If the two conditions are met, the terminal sets a delay function according to the delay time and waits for the completion of the execution of the delay function. For example, the delay time is obtained as delay, then the delay function is set, the timeout value of the delay function is set as delay, then the delay function is executed and the completion of the delay function is waited.
Therefore, in this embodiment, the target request is re-sent to the server after the preset delay, which avoids the occurrence of situations such as overlapping sending of the target request in a short time, reduces unnecessary data processing procedures, and enables the re-sending procedure to be performed in order, thereby improving the work efficiency of re-sending the target request.
In order to make the number of allowed retransmissions updated with the actual number of retransmissions, the step of retransmitting the target request to the server after the preset delay (i.e., step S11) may include the following steps:
and subtracting the number of the target request allowed resending times in the resending request parameter by one time to obtain a new number of the allowed resending times. For example, if the number of times of retransmission is allowed to be greater than 1 and the condition execution result returns true, the retransmission process of the target request is performed, that is, the actual number of times of retransmission of the target request is added once, the retry count is decreased once, so that the number of times of retransmission is allowed to be correspondingly decreased along with the increase of the actual number of times of retransmission, thereby implementing effective management of the number of times of retransmission allowed.
In order to avoid unnecessary data processing procedures, the present embodiment may further include the following steps:
receiving correct information sent by a server, wherein the correct information is used for indicating that the target request is successfully received; and prompting that the target request is successfully sent according to the correct information. For example, as shown in fig. 2, when the server successfully receives the Fetch request, the terminal passes the result returned by the server to the do-not-process function, executes the do-not-process function, and then ends the request.
Therefore, the occurrence of an event that the target request is retransmitted under the condition that the server successfully receives the target request is avoided, unnecessary data processing processes are reduced, the working efficiency of transmitting the target request is improved, the server is ensured to successfully receive the received target request, and the efficiency of retransmitting the target request is improved.
As shown in fig. 3, the device 3 for requesting transmission includes:
the receiving module 31 is configured to receive error information sent by the server, where the error information is used to indicate that a target request is a network request sent by the terminal to the server.
The determining module 32 is configured to determine whether the target request meets a preset resending condition, and determine whether the number of times of resending the target request is greater than a preset number of times, where the preset resending condition includes a preset request type and a preset request content.
If the target request meets the preset resending condition and the number of times of resending permission of the target request is greater than the preset number of times, the sending module 33 is configured to resend the target request to the server after a preset time delay.
The device for requesting transmission provided by the embodiment of the application has the same technical characteristics as the method for requesting transmission provided by the embodiment, so that the same technical problems can be solved, and the same technical effects can be achieved.
As shown in fig. 4, the electronic device 4 includes a memory 41 and a processor 42, where the memory stores a computer program that can run on the processor, and the processor executes the computer program to implement the steps of the method provided in the foregoing embodiment.
Referring to fig. 4, the electronic device further includes: a bus 43 and a communication interface 44, the processor 42, the communication interface 44 and the memory 41 being connected by the bus 43; the processor 42 is for executing executable modules, such as computer programs, stored in the memory 41.
The Memory 41 may include a high-speed Random Access Memory (RAM) and may also include a non-volatile Memory (non-volatile Memory), such as at least one disk Memory. The communication connection between the network element of the system and at least one other network element is realized through at least one communication interface 44 (which may be wired or wireless), and the internet, a wide area network, a local network, a metropolitan area network, and the like can be used.
The bus 43 may be an ISA bus, a PCI bus, an EISA bus, or the like. The bus may be divided into an address bus, a data bus, a control bus, etc. For ease of illustration, only one double-headed arrow is shown in FIG. 4, but that does not indicate only one bus or one type of bus.
The memory 41 is used for storing a program, and the processor 42 executes the program after receiving an execution instruction, and the method performed by the apparatus defined by the process disclosed in any of the foregoing embodiments of the present application may be applied to the processor 42, or implemented by the processor 42.
The processor 42 may be an integrated circuit chip having signal processing capabilities. In implementation, the steps of the above method may be performed by instructions in the form of hardware, integrated logic circuits, or software in the processor 42. The Processor 42 may be a general-purpose Processor, and includes a Central Processing Unit (CPU), a Network Processor (NP), and the like; the device can also be a Digital Signal Processor (DSP), an Application Specific Integrated Circuit (ASIC), a Field-Programmable Gate Array (FPGA), or other Programmable logic devices, discrete Gate or transistor logic devices, discrete hardware components. The various methods, steps, and logic blocks disclosed in the embodiments of the present application may be implemented or performed. A general purpose processor may be a microprocessor or the processor may be any conventional processor or the like. The steps of the method disclosed in connection with the embodiments of the present application may be directly implemented by a hardware decoding processor, or implemented by a combination of hardware and software modules in the decoding processor. The software module may be located in ram, flash memory, rom, prom, or eprom, registers, etc. storage media as is well known in the art. The storage medium is located in a memory 41, and a processor 42 reads information in the memory 41 and performs the steps of the method in combination with hardware thereof.
Embodiments of the present application also provide a computer readable medium having a non-volatile program code executable by a processor, where the program code causes the processor to execute the method provided by the above embodiments.
The computer-readable medium having the processor-executable nonvolatile program code provided in the embodiments of the present application has the same technical features as the method, the apparatus, and the electronic device for requesting transmission provided in the embodiments, so that the same technical problems can be solved, and the same technical effects can be achieved.
Finally, it should be noted that: the above embodiments are only used to illustrate the technical solution of the present invention, and not to limit the same; while the invention has been described in detail and with reference to the foregoing embodiments, it will be understood by those skilled in the art that: the technical solutions described in the foregoing embodiments may still be modified, or some or all of the technical features may be equivalently replaced; and the modifications or the substitutions do not make the essence of the corresponding technical solutions depart from the scope of the technical solutions of the embodiments of the present invention.
Claims (8)
1. A method for sending a request is applied to a terminal, and is characterized by comprising the following steps:
receiving error information sent by a server, wherein the error information is used for indicating that a target request is received wrongly, and the target request is a network request sent to the server by the terminal;
judging whether the target request meets a preset resending condition or not, and judging whether the number of times of resending permission of the target request is greater than the preset number of times or not, wherein the preset resending condition is used for representing a preset request type and preset request content of the target request;
if the target request meets a preset resending condition and the number of times of resending permission of the target request is greater than the preset number of times, resending the target request to the server after a preset delay;
further comprising:
before the target request is sent to the server for the first time, acquiring a request parameter in the target request, and combining the request parameter and a retry parameter to obtain a re-request parameter, wherein the retry parameter comprises the number of times of re-sending permission of the target request, a preset re-sending condition and a preset time delay;
the resending of the target request to the server after the preset time delay includes:
and acquiring the preset time delay from the re-request parameter, and re-sending the target request to the server after the preset time delay.
2. The method of claim 1, wherein the determining whether the target request meets a preset retransmission condition and whether the number of allowed retransmissions of the target request is greater than a preset number comprises:
and acquiring the number of times of allowed retransmission and the preset retransmission condition from the retransmission request parameter, judging whether the target request meets the preset retransmission condition, and judging whether the number of times of allowed retransmission is greater than the preset number.
3. The method of claim 1, wherein after determining whether the target request meets a preset retransmission condition and determining whether the number of allowed retransmissions of the target request is greater than a preset number, the method further comprises:
if the target request does not accord with the preset resending condition, or the number of times of allowed resending of the target request is less than or equal to the preset number, or the target request does not accord with the preset resending condition and the number of times of allowed resending of the target request is less than or equal to the preset number, ending the sending process of the target request.
4. The method of claim 1, wherein after resending the target request to the server after a preset delay, further comprising:
and subtracting the number of times of the target request allowed to be retransmitted in the retransmission request parameter by one time to obtain a new number of times of the target request allowed to be retransmitted.
5. The method of claim 1, further comprising:
receiving correct information sent by a server, wherein the correct information is used for indicating that the target request is successfully received;
and prompting that the target request is successfully sent according to the correct information.
6. An apparatus for requesting transmission, comprising:
the system comprises a receiving module, a sending module and a receiving module, wherein the receiving module is used for receiving error information sent by a server, the error information is used for indicating that a target request receives errors, and the target request is a network request sent to the server by a terminal;
the judging module is used for judging whether the target request meets a preset resending condition or not and judging whether the number of times of resending permission of the target request is greater than the preset number of times or not, wherein the preset resending condition comprises a preset request type and preset request content;
if the target request meets a preset resending condition and the number of times of resending permission of the target request is greater than a preset number of times, the sending module is used for sending the target request to the server again after a preset time delay;
further comprising:
a merging module, configured to obtain a request parameter in the target request before the target request is sent to the server for the first time, and merge the request parameter and a retry parameter to obtain a retry parameter, where the retry parameter includes a number of times of allowing resending of the target request, a preset resending condition, and a preset delay;
the sending module is specifically configured to:
and acquiring the preset time delay from the re-request parameter, and re-sending the target request to the server after the preset time delay.
7. An electronic device comprising a memory and a processor, wherein the memory stores a computer program operable on the processor, and wherein the processor implements the steps of the method of any of claims 1 to 5 when executing the computer program.
8. A computer-readable medium having non-volatile program code executable by a processor, wherein the program code causes the processor to perform the method of any of claims 1 to 5.
Priority Applications (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| CN201910316975.8A CN110034857B (en) | 2019-04-17 | 2019-04-17 | Request sending method and device and electronic equipment |
Applications Claiming Priority (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| CN201910316975.8A CN110034857B (en) | 2019-04-17 | 2019-04-17 | Request sending method and device and electronic equipment |
Publications (2)
| Publication Number | Publication Date |
|---|---|
| CN110034857A CN110034857A (en) | 2019-07-19 |
| CN110034857B true CN110034857B (en) | 2021-12-21 |
Family
ID=67239303
Family Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| CN201910316975.8A Active CN110034857B (en) | 2019-04-17 | 2019-04-17 | Request sending method and device and electronic equipment |
Country Status (1)
| Country | Link |
|---|---|
| CN (1) | CN110034857B (en) |
Families Citing this family (10)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| CN112306701B (en) * | 2019-07-25 | 2024-05-03 | 中移动信息技术有限公司 | Service fusing method, device, equipment and storage medium |
| CN110570277A (en) * | 2019-08-29 | 2019-12-13 | 北京趣拿软件科技有限公司 | order dispatching method and device |
| CN111131392A (en) * | 2019-11-27 | 2020-05-08 | 北京文渊佳科技有限公司 | Method, device, electronic equipment and medium for processing message |
| CN111176866A (en) * | 2020-01-03 | 2020-05-19 | 精硕科技（北京）股份有限公司 | Data interaction method and electronic equipment |
| CN111447262A (en) * | 2020-03-23 | 2020-07-24 | 北京达佳互联信息技术有限公司 | Request sending method, client and storage medium |
| CN111526181B (en) * | 2020-04-01 | 2022-11-11 | 北京皮尔布莱尼软件有限公司 | Data request processing method and system and computing device |
| CN111629056B (en) * | 2020-05-27 | 2023-04-07 | 浙江百世技术有限公司 | Network request processing method and application |
| CN112099998A (en) * | 2020-09-24 | 2020-12-18 | 百度在线网络技术（北京）有限公司 | Processing method and device for applet loading failure, electronic equipment and storage medium |
| CN113300943B (en) * | 2021-05-24 | 2023-04-18 | 维沃移动通信有限公司 | Information sending method, device, equipment and readable storage medium |
| CN116107778B (en) * | 2023-04-13 | 2023-07-11 | 深圳复临科技有限公司 | Front-end event response realization method, device, terminal equipment and readable storage medium |
Citations (6)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| CN1815943A (en) * | 2005-02-01 | 2006-08-09 | 株式会社Ntt都科摩 | Communication system, transmitter and receiver |
| JP2009239456A (en) * | 2008-03-26 | 2009-10-15 | Nec Infrontia Corp | Communication module, communication apparatus, communicating method, and program |
| CN105577772A (en) * | 2015-12-17 | 2016-05-11 | 腾讯科技（北京）有限公司 | Material receiving method, material uploading method and device |
| CN106101761A (en) * | 2016-06-30 | 2016-11-09 | 乐视控股（北京）有限公司 | A kind of desktop loading method and intelligent television |
| CN108366091A (en) * | 2018-01-10 | 2018-08-03 | 深圳市金立通信设备有限公司 | Network request processing method, terminal and computer-readable medium |
| CN108809483A (en) * | 2017-04-28 | 2018-11-13 | 维沃移动通信有限公司 | A kind of the acquisition processing method and user terminal of system information |
-
2019
- 2019-04-17 CN CN201910316975.8A patent/CN110034857B/en active Active
Patent Citations (6)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| CN1815943A (en) * | 2005-02-01 | 2006-08-09 | 株式会社Ntt都科摩 | Communication system, transmitter and receiver |
| JP2009239456A (en) * | 2008-03-26 | 2009-10-15 | Nec Infrontia Corp | Communication module, communication apparatus, communicating method, and program |
| CN105577772A (en) * | 2015-12-17 | 2016-05-11 | 腾讯科技（北京）有限公司 | Material receiving method, material uploading method and device |
| CN106101761A (en) * | 2016-06-30 | 2016-11-09 | 乐视控股（北京）有限公司 | A kind of desktop loading method and intelligent television |
| CN108809483A (en) * | 2017-04-28 | 2018-11-13 | 维沃移动通信有限公司 | A kind of the acquisition processing method and user terminal of system information |
| CN108366091A (en) * | 2018-01-10 | 2018-08-03 | 深圳市金立通信设备有限公司 | Network request processing method, terminal and computer-readable medium |
Also Published As
| Publication number | Publication date |
|---|---|
| CN110034857A (en) | 2019-07-19 |
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| CN110034857B (en) | Request sending method and device and electronic equipment | |
| CN110233881B (en) | Service request processing method, device, equipment and storage medium | |
| CN111211878B (en) | File transmission method, device and system and electronic equipment | |
| CN106612284B (en) | Streaming data transmission method and device | |
| CN108234087B (en) | Data transmission method and sending end | |
| CN110247736B (en) | Data transmission method and device | |
| CN113765976A (en) | Communication method and system | |
| CN107645357B (en) | Recovery method and device for incomplete transmitted file | |
| CN111835682B (en) | Connection control method, system, device and computer readable storage medium | |
| CN110913431A (en) | Data wireless transmission method and device, computer equipment and storage medium | |
| CN112804682B (en) | Data transmission method and device, readable medium and electronic equipment | |
| KR102071955B1 (en) | Method for processing multicast in distributed cache environment, and distributed cache server using the same | |
| US8370443B2 (en) | Reliable messaging using publish subscribe mechanism | |
| CN113852445A (en) | Method, system, equipment and storage medium for improving data transmission reliability | |
| CN109460215B (en) | Application control method and device | |
| CN117040692A (en) | Method and device for transmitting service data, electronic equipment and storage medium | |
| CN113742354B (en) | Message confirmation method and device, storage medium and electronic equipment | |
| CN111818582A (en) | Data transmission method and device and electronic equipment | |
| CN116582826A (en) | Message transmission method, electronic equipment and storage medium | |
| CN116366629A (en) | File uploading and acquiring method, computer equipment and storage medium | |
| CN111447046B (en) | Service data transmission method, device, equipment and storage medium | |
| CN113259490B (en) | Multi-level node network data transmission method based on UDP transmission protocol | |
| CN111147540B (en) | File transmission method, device, equipment and storage medium | |
| EP2706698A2 (en) | Transfer device and transfer method using ARQ with Packet ID and several ARQ phases | |
| CN110971535B (en) | Communication congestion control method, device, equipment and storage medium |
Legal Events
| Date | Code | Title | Description |
|---|---|---|---|
| PB01 | Publication | ||
| PB01 | Publication | ||
| SE01 | Entry into force of request for substantive examination | ||
| SE01 | Entry into force of request for substantive examination | ||
| GR01 | Patent grant | ||
| GR01 | Patent grant |