JP7220880B1 - Systems, methods, and computer readable media for data access - Google Patents

Abstract

A system, method, and computer-readable medium for data access that can realize more efficient resource distribution and prevent server down. A method for data access includes the steps of receiving a request, receiving a status parameter of an endpoint corresponding to the request, receiving a number of times the request was received within a time period, and determining an amount of delay time for sending the request based on the status parameter of the endpoint or the number of times the request is received within the time period. [Selection drawing] Fig. 4

Description

The present invention relates to data access, and more particularly to data access by a server.

Data access over the Internet typically involves a user terminal (smartphone, tablet, computer, etc.) used by the user, an application (or application software) running on the user terminal, and the application communicating with the user terminal. A server (or application server) or the like is involved.

A user can initiate a data request through the application's user interface, which may involve clicking, tapping, or scrolling actions. The request is then transmitted from the user terminal to the server. Finally, the server sends a response to the request to the user terminal, completing the data access.

As the number of such users accessing the server increases, it becomes important to keep the server stable and maintain user experience during data access.

A method according to one embodiment of the invention is a method for data access performed by one or more computers comprising the steps of: receiving a request; and receiving a status parameter of an endpoint corresponding to the request. , receiving the number of times the request is received within the time period; and determining the amount of delay time for sending the request based on the status parameter of the endpoint or the number of times the request is received within the time period. and

A system according to one embodiment of the present invention is a system for data access including one or more computer processors, the one or more computer processors executing machine-readable instructions to receive requests; receiving a status parameter of the endpoint corresponding to the request; receiving the number of times the request was received within the time period; and based on the status parameter of the endpoint or the number of times the request was received within the time period. , and determining the amount of delay time for sending the request.

A computer-readable medium according to one embodiment of the present invention is a non-transitory computer-readable medium containing a program for accessing data, the program instructing one or more computers to receive a request; receiving a status parameter of the corresponding endpoint; receiving the number of times the request was received within the time period; and determining a delay time length for sending the request.

1 is an exemplary flow chart illustrating a conventional data access method; 1 is a schematic diagram of a communication system according to some embodiments of the present invention; FIG. 1 is an exemplary block diagram of a user terminal according to some implementations of the present invention; FIG. 4 is an exemplary flow chart according to some embodiments of the present invention; FIG. 4 is an exemplary timeline diagram according to some implementations of the present invention; 4 is an exemplary flow chart according to some embodiments of the present invention; 4 is a graph showing exemplary criteria for determining the amount of delay time for sending a request from a user terminal to a server according to some embodiments of the present invention; 4 is a graph showing exemplary criteria for determining the amount of delay time for sending a request from a user terminal to a server according to some embodiments of the present invention; 4 is a graph showing exemplary criteria for determining the amount of delay time for sending a request from a user terminal to a server according to some embodiments of the present invention; 4 is a graph showing exemplary criteria for determining the amount of delay time for sending a request from a user terminal to a server according to some embodiments of the present invention; It is an example of a request table 118 . 1 is an example of an endpoint status table 112; It is an example of the user status table 114 . It is an example of a user database 310 . 4 is an exemplary flow chart according to some embodiments of the present invention;

Conventional data access methods between user terminals and servers have several problems to be solved.

Conventionally, when a user terminal receives a request for data from a user, the user terminal immediately sends the request to the server for data. If the user initiates the same request many times within a short period of time, the user terminal will send the same request to the server many times, increasing the burden/burden on the server. This can result in server outages and significant delays in data access. For example, if the Internet connection status of the user terminal is not good, the user may feel slow response to operations on the user terminal. Therefore, the user may repeatedly click the update button on the user interface while waiting for the update. However, repeated requests like this can actually hinder the access process and degrade the user experience. In some cases, repeated requests from users may even reduce the server's ability or capacity to provide data access to other users.

Conventionally, such user terminals have no means of knowing the information to which data access is directed. For example, the user terminal has no means of knowing the endpoint information corresponding to the request. Such information may include the status of burden (or load), health, priority, or severity of the endpoint. As such, data access cannot be handled in a customized or efficient manner for different requests corresponding to different endpoints.

The present invention discloses a method and system for determining when to send a request from the user terminal to the server. The transmission timing may be determined by the reception frequency of the request at the user terminal. The timing of the transmission may be determined by the status of the endpoint corresponding to the request. The timing of the transmission may be determined by the contribution score (or contribution level) of the user who initiated the request. Therefore, optimal timing for sending the request to the server can be achieved. Technical effects of the present invention include prevention of server failure, customized efficient processing of data access (efficient resource allocation), and the like.

FIG. 1 shows an exemplary flow chart illustrating a conventional data access method.

At step S100, the user terminal receives a request from a user in a function or user interface (UI). For example, the user may initiate the request by clicking or tapping a button on the UI of an application installed on the user terminal.

At step S102, the user terminal sends the request to the server where the data corresponding to the request resides.

At step S104, the server sends a response to the user terminal. The response contains the data requested by the user (or the application on the user terminal).

At step S106, the application (or a function of the application) checks whether the response data contains an error or indicates a server outage. If no, flow proceeds to step S108. If yes, flow proceeds to step S110.

In step S108, the user terminal displays the result of the request on the UI (of the application) based on the response data. Data access is successful.

In step S110, the user terminal displays a message indicating error, server busy, or server down based on the response data.

FIG. 2 shows a schematic diagram of a communication system according to some embodiments of the present invention.

The communication system 1 can provide a live streaming service with interaction via content. As used herein, "content" refers to digital content that can be played on a computer device. In other words, the communication system 1 enables users to participate in real-time interactions with other users online. The communication system 1 includes a plurality of user terminals 10 , a backend server 30 and a streaming server 40 . The user terminal 10, the backend server 30, and the streaming server 40 are connected via a network 90 (which may be the Internet, for example). The backend server 30 may be a server that synchronizes interactions between the user terminal and/or the streaming server 40 . In some embodiments, the backend server 30 may be an application (APP) provider's server. The streaming server 40 is a server for processing or providing streaming data or video data. In some embodiments, the backend server 30 and the streaming server 40 may be independent servers. In some embodiments, the backend server 30 and the streaming server 40 may be integrated into one server. In some embodiments, the user terminal 10 is a client device for live streaming services. In some implementations, the user terminal 10 may be referred to as a viewer, streamer, anchor, podcaster, audience, listener, or the like. The user terminal 10, the backend server 30, and the streaming server 40 are each an example of an information processing device. In some implementations, the streaming may be live streaming or video playback. In some implementations, streaming may be audio streaming and/or video streaming. In some implementations, streaming may include content such as online shopping, talk shows, talent shows, entertainment events, sporting events, music videos, movies, comedies, concerts, and the like.

FIG. 3 shows an exemplary block diagram of a user terminal according to some implementations of the present invention.

The user terminal 100 includes a user interface 102, an endpoint status monitor 104, a user status monitor 106, a transmission timing controller 108, a transmission unit 110, an endpoint status table 112, a user status table 114, a delay policy Includes table 116 and request table 118 .

The user interface 102 is configured to enable interaction between a user of the user terminal 100 and the user terminal 100 . The user interface 102 may include visual, audio and touch sensors for receiving visual, audio and touch input from the user. The user interface 102 may correlate with the functionality of a page or application for accepting instructions from the user. The user terminal 100 can receive requests from the user via the user interface 102 . The received requests may be stored in the request table 118 . If the user sends repeated requests, the number of times the request is received (eg, within a certain period of time) is also recorded in the request table 118 .

The endpoint status monitor 104 is configured to monitor the status of endpoints. The endpoint responds to the request from the user or is the destination of the request. The endpoint exists in a server outside the user terminal 100 . The endpoint status monitor 104 can access the endpoint database 300 (eg, via the Internet) to obtain status parameters for the endpoint. That status parameter for that endpoint is then stored in the endpoint status table 112 . The endpoint database 300 may reside on the server to which the endpoint corresponding to the request resides. In some implementations, the endpoint database 300 may reside on another server.

The user status monitor 106 is configured to monitor the status of the user. The user status monitor 106 can access the user database 310 (eg, via the Internet) to obtain status parameters for the user. The user database 310 may reside on the server to which the endpoint corresponding to the request resides. In some implementations, the user database 310 may reside on another server. The status parameter may be or include a contribution score corresponding to the user. The status parameter may be a level corresponding to the user. That status parameter for that user is then stored in that user status table 114 . In some embodiments, the contribution score and/or the level may increase based on the user's commenting behavior, gift sending behavior, viewing behavior, and payment behavior on the live streaming platform. good.

The send timing controller 108 is configured to determine when to send the request (or the amount of delay to send the request) to the server where the endpoint corresponding to the request resides. The transmit timing controller 108 may access the request table 118 to receive the number of times the request has been received over a period of time. The transmit timing controller 108 may access the endpoint status table 112 and receive the status parameters of the endpoint corresponding to the request. The transmission timing controller 108 may access the user status table 114 and receive the status parameters (such as the contribution score) of the user. The transmit timing controller 108 then consults the delay policy table 116 to determine the amount of delay time for transmitting the request.

The delay policy table 116 is configured to store policies or criteria for determining the amount of delay time for sending the request.

In some embodiments, the delay time length is determined to be longer the more times the request is received within the period. For example, the delay time length may be exponentially proportional to the number of times the request is received within the period. If a user sends the same request over and over again, the exponential delay mechanism will cause the user to waste/reduce server resources (such as the server's capacity, bandwidth, CPU usage and/or memory usage). Over consumption/occupancy can be prevented. In some implementations, the delay rule acts as a punishment mechanism for those users who tend to keep sending requests over and over again. This enables efficient distribution/utilization of server resources and prevents the server from being overloaded or stopped.

In some embodiments, the delay time length is determined to be longer when the status parameter of the endpoint corresponding to the request indicates a relatively severe condition of the endpoint.

In some embodiments, a more severe condition indicates that the endpoint is more important. For example, an endpoint for functionality such as making a payment or sending a gift may be judged to be more critical than the endpoint for other functionality such as commenting, and may have a higher value for its status parameter. Therefore, the longer the delay time length, the higher the reliability of successful access may be.

In some embodiments, a more severe condition indicates a more unhealthy condition for the endpoint. An unhealthy endpoint means that the endpoint is busy, overloaded, or in any abnormal state. For example, the server's resources for proper operation of the endpoint may not be ready or sufficient at a particular time. A delay mechanism can allow the endpoint (or the server) sufficient time to recover from an unhealthy state and can ensure more reliable data access. A delay mechanism can prevent a situation in which many requests from different user terminals reach the endpoint (or the server) at the same time.

The status parameter of the endpoint may include a prediction of the endpoint's status. For example, the status parameter may indicate whether the endpoint will be busy, overloaded, or in some abnormal state at some point in the future. Therefore, the delay time length can be determined according to the predicted status of the endpoint to optimize data access. The endpoint status prediction may be performed by a machine learning model that may be implemented in the endpoint database 300 .

In some implementations, the delay time length is determined to be shorter when the contribution score (of the user who initiated the request) is higher. In some implementations, the delay time length is determined to be longer when the contribution score (of the user who initiated the request) is lower. A higher contribution score may indicate that the corresponding user has more comment behavior, gift sending behavior, viewing behavior, and payment/deposit behavior on the live streaming platform. In other words, the user with a high contribution score has a "high" contribution to the platform. Therefore, it is expected that the user with a higher degree of contribution will have a better data access experience. Determining the delay time length according to the contribution score can optimize data access for different users when available resources are limited. In some implementations, the opposite strategy may be applied if the Internet and/or servers (endpoints) are in poor condition. For example, if a server/endpoint is detected to be in a bad state, ensure that the length of time delay for requests from more contributing users is long enough to ensure successful data access for that user. may be determined.

The request table 118 is configured to store requests scheduled to be sent to the server. The request table 118 may refer to or include a request queue. The request table 118 is configured to store received requests and information associated with the requests. In some implementations, the number of times a request has been received is stored with the request. In some implementations, the delay time length (or transmission timing) is stored with the request.

The sending unit 110 is configured to send the request to the server, eg via the Internet. The transmitting unit 110 may access the request table 118 for the determined transmission timing (or the determined delay time length).

FIG. 4 shows an exemplary flow chart according to some embodiments of the invention.

At step S300, the user terminal (eg, user terminal 100) receives a request from a user. The request may be received via a function or UI (user interface) of an application installed on the user terminal. For example, the user can initiate the request by clicking or tapping a button on the UI (such as a refresh button) or function of the application. The feature may be a leaderboard feature, and the user can initiate a request to get the latest leaderboard data.

Step S302 includes steps S3020, S3022, and S3024.

At step S3020, for example, the user's contribution score is received by the user status monitor .

At step S3022, for example, the user interface 102 detects the number of times the request has been received.

At step S3024, the status parameters of the endpoint corresponding to the request are received, for example, by the endpoint status monitor 104 . The status parameter may indicate the status or status prediction of the endpoint.

At step S304, for example, by the transmission timing controller 108, the delay time length for the request transmission is determined. The delay time length may be determined based on the number of times the request is received (over a period of time), the status parameters of the endpoint, and/or the contribution score of the user.

At step S306, the request is entered or updated in a request table or request queue, such as the request table 118. FIG. The determined time delay length for sending the request is also stored in the request table along with the request.

At step S308, the user terminal determines whether the user still remains at the user interface or function that initiated the request. If no, flow proceeds to step S310. If yes, flow proceeds to step S312. In some implementations, the determination may be performed by the user interface 102 or the application.

At step S310, the request is deleted from the request table. It is determined that the user has left the function or user interface from which the request was initiated and does not need to continue to access the data. This mechanism can prevent unnecessary waste of resources.

At step S312, the user terminal sends the request to the server, for example by means of the sending unit 110 . The request is transmitted at the determined transmission timing (or after a determined delay time length). Within the user terminal there may be a clock unit configured to determine when the delay time length has elapsed.

At step S314, the server sends a response to the user terminal. The response includes data requested by the user, such as leaderboard information.

At step S316, the application (or the function of the application) checks whether the response data contains an error or indicates a server outage. If no, flow proceeds to step S318. If yes, flow proceeds to step S320.

In step S318, the user terminal displays the result of the request on the UI (of the application) based on the response data. Data access is successful.

In step S320, the user terminal displays a message indicating error, server busy, or server down based on the response data.

Note that in the embodiment shown in FIG. 4, there is a route from step S3024 to step S320. In this embodiment, if the status parameter received at step S3024 indicates that the server/endpoint is in a very bad state, such as down, flow proceeds directly to step S320. Therefore, unnecessary resource consumption and data transmission can be prevented by skipping steps S304 to S316 when the server/endpoint is in a stopped state. This mechanism benefits both the user terminal and the server.

FIG. 5 shows an exemplary timeline diagram according to some implementations of the invention.

In step S500, the user terminal receives a request and detects the number of times the request has been made (or the number of times the request has been received).

At step S502, the user terminal accesses the endpoint database to request the endpoint (EP) status (or status prediction) of the endpoint corresponding to the request.

At step S504, the endpoint database returns the endpoint status to the user terminal.

At step S506, the user terminal accesses the user database to request user status data, such as user contribution data. The user status data corresponds to the user who initiated the request.

At step S508, the user database returns the user status data to the user terminal.

At step S510, the user terminal accesses the delay policy database (which may or may not reside in the user terminal) and checks the delay policy for sending the request to the server. The delay policy may be dependent on or correlated to the number of requests, the endpoint status (or status prediction), and/or the user status data.

At step S512, the user terminal determines the timing (or the delay time length) to send the request to the server based on the delay policy accessed at step S510. The user terminal updates information in the request queue.

At step S514, the user terminal determines that the user is still on the UI that initiated the request, and determines that the delay time length has passed.

In step S516, the user terminal transmits the request to the server at the determined transmission timing, and requests transmission of data corresponding to the request.

At step S518, the server returns a response containing the requested data to the user terminal. This allows the data access to complete normally.

FIG. 6 shows an exemplary flowchart according to some embodiments of the invention.

At step S600, the server receives requests from a plurality of different user terminals.

Step S602 includes step S6020 and step S6022.

At step S6020, the server accesses a user database (which may or may not reside on the server) and requests the contribution score of the user who initiated the request.

At step S6022, the server accesses an endpoint database (which may or may not reside on the server) and requests the status (or status prediction) of the endpoint corresponding to the request.

At step S604, the server determines when to send a response for each request. A response transmission timing is a timing for transmitting a response corresponding to a request to the corresponding user terminal.

In some implementations, the timing of sending the response corresponding to a request may be determined according to the contribution score of the user initiating the request. For example, if the corresponding request was initiated by a user with a high contribution score, it may decide to send the response sooner/faster. For example, if the corresponding request was initiated by a user with a low contribution score, it may decide to later/delay the timing of sending the response. This mechanism efficiently distributes resources so that high-contribution users can get their requested data faster.

In some implementations, the timing of sending the response corresponding to a request may be determined based on the status of the endpoint corresponding to the request. For example, if the status data indicates that the endpoint of the corresponding request is healthier, the response sending timing may be determined to be sooner/faster. For example, if the status data indicates that the endpoint of the corresponding request is more unhealthy, the response sending timing may be determined later/later. This mechanism dynamically adjusts the load or processing to different endpoints and ensures that all data access is done in a reliable manner.

At step S606, the server sends the response to the user terminal at the timing determined at step S604, thereby completing the data access.

FIG. 7 shows a graph illustrating exemplary criteria for determining the amount of delay time for sending a request from a user terminal to a server according to some embodiments of the present invention.

The delay time length is determined based on the number of times the request is received (within a certain period of time). There is an exponential relationship between the delay time length and the number of times the request is received. A maximum delay time is set in the delay time length. FIG. 7 may correspond to criteria stored in the delay policy table 116 of interest.

FIG. 8 shows a graph illustrating exemplary criteria for determining the amount of delay time for sending a request from a user terminal to a server according to some embodiments of the present invention.

The delay time length is determined based on the number of times the request is received (within a certain period of time). There is a linear relationship between the delay time length and the number of times the request is received. A maximum delay time is set in the delay time length. FIG. 8 may correspond to criteria stored in the delay policy table 116 of interest.

FIG. 9 presents a graph illustrating exemplary criteria for determining the amount of delay time for sending a request from a user terminal to a server according to some embodiments of the present invention.

The delay time length is determined based on the number of times the request is received (within a certain period of time). There is a logarithmic relationship between the delay time length and the number of times the request is received. A maximum delay time is set in the delay time length. FIG. 9 may correspond to criteria stored in the delay policy table 116 of interest.

In one embodiment of the invention, the user terminal may determine whether the request is received for the first time. If the request is received for the first time, the user terminal does not apply any delay to the request. If the request is not received for the first time, the user terminal applies the delays disclosed herein to the request. For example, initial requests are processed in normal mode (no delay) and repeated requests are processed in exponential delay mode.

FIG. 10 presents a graph illustrating exemplary criteria for determining the amount of delay time for sending a request from a user terminal to a server according to some embodiments of the present invention.

The delay time length is determined by the importance level of the endpoint corresponding to the request. There is an exponential relationship between the delay time length and the importance level. A maximum delay time is set in the delay time length. FIG. 10 may correspond to criteria stored in the delay policy table 116 of interest.

FIG. 11 shows an example of the request table 118. As shown in FIG.

In this example, for each request received, the corresponding user (or user terminal) that initiated the request, the corresponding endpoint, the number of receptions, and the length of the delay are recorded in a table. The number of receptions may be updated with information from the user interface. The delay time length may be updated with reference to the delay policy table 116 . In some implementations, each time the number of requests or the endpoint severity level is updated, the corresponding delay time length is updated accordingly.

FIG. 12 shows an example of the endpoint status table 112. As shown in FIG.

In this example, the relevant severity level or unhealthy level for each endpoint is recorded in a table.

FIG. 13 shows an example of the user status table 114. As shown in FIG.

In this example, the status parameters (the contribution score, level, etc.) of the user U1 (the user of the user terminal) are recorded in the table.

FIG. 14 shows an example of the user database 310. As shown in FIG.

As shown, the user database 310 contains various parameters that differ from user to user.

FIG. 15 shows an exemplary flow chart according to some embodiments of the invention.

In step S1500, a user terminal detects a request from a user.

At step S1502, the user terminal determines a delay time for sending the requested request to the server. In some implementations, the delay time may be determined based on the status of the endpoint corresponding to the request and/or based on the user's contribution score.

At step S1504, the request is entered or scheduled in a request queue or request table.

At step S1506, the user terminal detects or receives the same request again within a predetermined period of time. This may be a scenario in which the user cannot wait for the results to be displayed and taps the same button again.

In step S1508, the delay time for sending the request to the server is updated based on the number of times the request is received. Steps S1506 and S1508 are repeated if the user repeatedly sends the request within a predetermined time period. For example, as shown in FIG. 7, FIG. 8 or FIG. 8, the delay time is extended as the number of times the request is received increases. In some implementations, it may act as a punishment mechanism for those users who tend to repeatedly refresh pages or functions on the application.

In step S1510, after the predetermined period of time has passed and after the delay time has passed, the user terminal determines that the user is still in the UI from which the request was initiated.

At step S1512, the user terminal sends the request to the server to request the requested data.

The present invention discloses an improved method and system for data access. Better allocating limited available resources by introducing a delay time for sending requests from the user terminal to the server based on request count, endpoint status, and/or contribution score; Server/endpoint outages can be prevented.

The processes and procedures described in the present invention, in addition to those explicitly described, can be implemented in software, hardware, or any combination thereof. For example, the processes and procedures described herein may be implemented by implementing logic corresponding to the processes and procedures in media such as integrated circuits, volatile memory, non-volatile memory, non-transitory computer-readable media, magnetic disks, and the like. It can be realized by Furthermore, the processes and procedures described herein can be implemented as computer programs corresponding to the processes and procedures, and can be executed by various computers.

Furthermore, the systems or methods described in the above embodiments may be integrated into programs stored on non-transitory computer-readable media such as solid-state storage devices, optical disk storage devices, magnetic disk storage devices, and the like. Alternatively, the program may be downloaded from a server via the Internet and executed by a processor.

Although the technical content and features of the present invention have been described above, many variations and modifications may be made to those skilled in the art to which the present invention pertains without departing from the teachings and disclosures of the present invention. It can be performed. Accordingly, the scope of the present invention is not limited to the embodiments disclosed, but includes other variations and modifications that do not depart from the invention, as covered by the appended claims.

1 communication system 10 user terminal 30 backend server 40 streaming server 90 network 100 user terminal 102 user interface 104 endpoint status monitor 106 user status monitor 108 transmission timing controller 110 transmission unit 112 endpoint status table 114 user status table 116 delay policy table 118 request table 300 endpoint database 310 user database S100, S102, S104, S106, S108, S110 steps S300, S302, S304, S306, S308, S310, S312, S314, S316, S318, S320, S3020, S3022, S3024 steps S500, S502, S504, S506, S508, S510, S512, S514, S516, S518 Steps S600, S602, S604, S606, S6020, S6022 Steps S1500, S1502, S1504, S1506, S1508, S1510, S1512 Steps R1512 R3 request
U1, U2, U3 User EP1, EP2, EP3 Endpoint T1, T2, T3 Delay time length

Claims (8)

A method for data access, comprising:
receiving a request;
receiving the number of times the request was received within a period of time;
determining a delay time length for sending the request based on the number of times the request is received within the time period;
receiving the request from a user at a user interface;
storing the request in a request queue;
determining that the user has left the user interface;
deleting the request from the request queue;
A method for data access, comprising: 2. The method for data access according to claim 1, wherein said delay time length is determined to be longer the greater the number of said requests received within said period. moreover,
receiving an endpoint status parameter corresponding to the request;
the determining step includes determining a delay time length for sending the request based on the status parameter of the endpoint and the number of times the request is received within the time period;
2. The method according to claim 1, characterized in that said delay time length is determined longer when said status parameter of said endpoint corresponding to said request indicates a relatively serious condition of said endpoint. Methods for data access as described. Furthermore ,
determining that the user remains on the user interface;
determining that the delay time length has elapsed;
sending the request to a server corresponding to the endpoint corresponding to the request ;
2. The method for data access of claim 1, comprising: 3. A method for data access according to claim 2, characterized in that said delay time length increases exponentially with the number of times said request is received within said period. Furthermore ,
receiving a contribution score corresponding to the user;
determining the delay time length based on the contribution score;
2. The method for data access of claim 1, comprising: 1. A system for data access, comprising one or more processors, wherein the one or more processors execute machine-readable instructions,
receiving a request;
receiving the number of times the request was received within a period of time;
determining a delay time length for sending the request based on the number of times the request is received within the time period;
receiving the request from a user at a user interface;
storing the request in a request queue;
determining that the user has left the user interface;
deleting the request from the request queue;
A system for data access, characterized by executing A non-transitory computer-readable medium containing a program for data access, wherein said program is stored on one or more computers by:
receiving a request;
receiving the number of times the request was received within a period of time;
determining a delay time length for sending the request based on the number of times the request is received within the time period;
receiving the request from a user at a user interface;
storing the request in a request queue;
determining that the user has left the user interface;
deleting the request from the request queue;
A computer-readable medium for causing execution of

Images