Web Queuing System
Publication Date: 2015-May-13
The IP.com Prior Art Database
Aim – To produce a highly available pod of servers that can respond very quickly to requests with a simple queue page, do not need to communicate centrally on every request (to allow almost infinite traffic) and yet can let requests through to an application in approximate order of first entry.
Page 01 of 2
Web Queuing System
Aim - To produce a highly available pod of servers that can respond very quickly to requests with a simple queue page, do not need to communicate centrally on every request (to allow almost infinite traffic) and yet can let requests through to an application in approximate order of first entry.
At present, most providers use a "virtual waiting room" which is a simple page stating that the end user is in a waiting room. However behind the scenes each request is treated individually and is allowed or not based on a pre-defined percentage. This means that a new end user arriving at the waiting room has the same chance of getting through on each request as a user who has been queuing for hours. The solution below doesn't require any special IP level equipment or long running requests to provide a fairer system.
In an ideal world, none of this is needed because the actual application being accessed can be designed to support traffic such as this. However in the real world, legacy systems and other factors mean that traffic must be limited in some manner. Using standard methods for message queueing, counters and load balancing HTTP requests, we provide a method to allow a queue to be handled by a web application
in a nearly accurate order of arrival but at a speed appropriate to the application. Browser to Web Server Basic Route
Standard routing patterns will be used to allow the request from the browser to any number of servers.
● DNS tactics such as round robin or location based resolution
● Load balancing
The web server will respond according to the rules described below. Web Server Response Rules
The web server will respond to a request by doing one of several things.
1. If the business server has requested this, the requests will all be passed through to the sales pages immediately and an entry shall added to the "passed through" list. A secret key encrypted with the IP address of the requester will be sent in a cookie. The requests will also be passed through to the sales pages when a cookie contains a correct secret key, encrypted
with the correct IP address for the requester and a flag to say that the user
has passed both the "passed through" list check and the re-capture check if enabled.
2. If there is no cookie attached, one shall be created and sent back to the browser along with the page (containing the re-capture if enabled). The cookie will consist of the date / time (to the millisecond) that it's given out and a version of this encrypted with the password (changed regularly - see later) and the IP address of the requester. It will also contain information as to whether the user has completed a re-capture item. An entry will be added to the "cookie...