KR101072612B1 - Wating number ticket management method - Google Patents

Abstract

The present invention provides a wait table management method, a resource management method, and a transaction server. The present invention provides a waiting table indicative of the access sequence number to user terminals connected without the waiting table, registers the waiting table provided to the user terminal in the waiting list, and uses the waiting list and the allocation list to process the average waiting table number per second. Calculates and sets an allowable wait table using the average wait table processing number per second and the wait list, and then determines whether to allocate resources by comparing the order of the wait table of the user terminal requesting resource allocation with the order of the allowed wait table, The waiting table of the resource-allocated user terminal is deleted from the waiting list and then registered in the allocation list.

Description

Waiting ticket management method {Wating number ticket management method}

The present invention relates to a technique for managing access to a user terminal for resource management of a network system. In particular, the present invention relates to a waiting table management method for managing using a waiting table based on a connection order for requesting resource allocation of each user terminal.

In general, a network system such as a Web server or a WAP server may cause a problem in that when a large number of users suddenly runaway in a short time, the connection process may be delayed or even the system may be down without operation.

This problem occurs because the network system handles the connection of many users using limited resources, and in particular, the network system handles the connection while maintaining the connection with all users.

Currently, this problem is solved by adding a server to handle users' access.

However, although the expansion of the server can accommodate the user's request, the user's request is more than a certain level because of the limited processing power of devices using limited resources such as DB (Database) or WAS (Web Application Server). This causes a problem that can no longer be processed. In addition, if the user's request is above a certain level, all services related to the limited resources are affected in addition to processing the request, and thus the entire service cannot be provided smoothly. In addition, in order to expand the server, there is a problem that additional cost as much as the number of server expansion is required.

An object of the present invention is to provide a standby table management method that enables a service processor to be stably executed without a load on a network system even when an accessor having a limit value capable of processing a limited resource is connected.

The present invention according to the first aspect for achieving the above technical problem provides a method for managing a waiting table in a network system that enables the use of services by allocating resources to user terminals. This waiting table management method comprises the steps of providing a waiting table indicative of the access sequence to user terminals connected without the waiting table, registering the waiting table provided to the user terminal in the waiting list, and resources of the user terminal connected with the waiting table. When the resource allocation is made according to the allocation request, the step of deleting the waiting table of the user terminal that has been allocated the resource from the waiting list and registering in the allocation list.

According to the above-described embodiment, the present invention can stably provide a service by checking a service use order, a waiter, a service giver, and a service user by issuing a waiting table for a requestor for resource allocation according to a connection order. .

1 is a conceptual view of a service according to an embodiment to which the present invention is applied.
FIG. 2 is a data flow diagram illustrating an example of achieving the service environment of FIG. 1.
3 is a flowchart illustrating a data in a service environment to which a waiting table management method according to an exemplary embodiment of the present invention is applied.
4 is a block diagram of a network system according to an embodiment of the present invention.
5 is a flowchart illustrating an operation of a network system according to an exemplary embodiment of the present invention.
FIG. 6 is a block diagram according to an exemplary embodiment of the service controller illustrated in FIG. 4.
FIG. 7 is a block diagram illustrating an embodiment of the transaction server illustrated in FIG. 4.
FIG. 8 is a diagram for describing a method of issuing a waiting table according to an embodiment of the present invention based on FIG. 4.
FIG. 9 is a diagram for describing a method of issuing a waiting table according to another embodiment of the present invention based on FIG. 4.
FIG. 10 is a diagram for describing a method for allowing resource allocation according to an embodiment of the present invention based on FIG. 9.
11 is a diagram illustrating a waiting list according to an embodiment of the present invention.
12 is a diagram illustrating an allocation list according to an embodiment of the present invention.

DETAILED DESCRIPTION Hereinafter, exemplary embodiments of the present invention will be described in detail with reference to the accompanying drawings so that those skilled in the art may easily implement the present invention. As those skilled in the art would realize, the described embodiments may be modified in various different ways, all without departing from the spirit or scope of the present invention. In the drawings, parts irrelevant to the description are omitted in order to clearly describe the present invention, and like reference numerals designate like parts throughout the specification.

Throughout the specification, when a part is said to "include" a certain component, it means that it can further include other components, without excluding other components unless specifically stated otherwise.

Now, a standby table management method, a transaction server, a service controller, and a network system will be described with reference to the accompanying drawings.

First, an example of a service to which the present invention may be applied will be conceptually described with reference to FIG. 1. 1 is a conceptual view of a service according to an embodiment to which the present invention is applied. In FIG. 1, the case of three users will be described as an example. Of course, the user of the service target of the present invention is not limited to the number, and all the user terminals connectable to the network system are the service target.

In a conventional manner, the user terminals 1, 2, 3 connect to the network system 20 in order to use the network system 20 of the present invention. In this case, it is assumed that the order of accessing the network system 20 is the order in which the user terminal 1 is the fastest and the next, in the order of the user terminal 2 and then the user terminal 3.

Then, the network system 20 generates a standby notification message including a waiting table and a waiting time (T1 or T2 or T3) in the order of the user terminal 1, the user terminal 2, and the user terminal 3 in the order of connection. send. The wait notification message is provided to a user terminal that cannot allocate resources because there are no available resources (resources that can be allocated to the user terminal) of the network system 20.

The wait notification message includes a wait identifier indicating the wait, and the wait identifier is included in the header information of the wait notification message or in the payload of the wait notification message. The standby identifier serves to indicate waiting for a connection to the network system 20. The wait table may be used as a wait identifier.

Therefore, when receiving the standby notification message, the user terminals 1, 2, and 3 terminate the connection to the network system 20, wait for the waiting time, and then reconnect to the network system 20. Here, the connection between the user terminal and the network system may be made under the initiative of the user terminal, or may be made under the initiative of the network system.

Meanwhile, the waiting times T1, T2, and T3 provided to the user terminals 1, 2, and 3 may be the same, or may not be the same.

In the case where the waiting times T1, T2, and T3 are the same, the waiting time is preferably set to a default value. Although the waiting times T1, T2, and T3 are the same, the user terminals 1, 2, and 3 have different access times to the network system 20, and accordingly, the user terminals 1, 2, 3 in the network system 20 are different. Since the time points for providing the waiting time are different from each other, the connection of the user terminals 1, 2, 3 according to the waiting time is different.

When the waiting times T1, T2, and T3 are different, the waiting time is preferably determined according to the resource usage state, and the longer the connection is, the longer the waiting time is. For example, the waiting time T1 provided to the user terminal 1 is the longest, and the waiting time T2 provided to the user terminal 2 is shorter than the waiting time T1, and the waiting time T provided to the user terminal 3 ( T3) is the shortest.

As a result, even if the waiting time is the same or different, the reconnection of the user terminal 1 is faster than the user terminals 2 and 3, and the reconnection of the user terminal 2 is faster than the user terminal 3.

Of course, the waiting time is provided to the user terminal which cannot allocate resources immediately, and is provided to the user terminal through the standby notification message.

Here, for the purposes of the present invention, the network system 20 uses the wait table to determine the connection order of the user terminal in order to calculate the wait time or allocate resources.

The network system 20 allocates resources by identifying a standby table capable of allocating resources in the current resource usage state, and selects a standby table of who is the resource user who has allocated the resource and who has finished using the resource. I can figure it out.

Hereinafter, an example of achieving the service with reference to FIG. 1 will be described with reference to FIG. 2. The following example with reference to FIG. 2 will be described with reference to, although not related to the present invention. FIG. 2 is a data flow diagram illustrating an example of achieving the service environment of FIG. 1. Hereinafter, all the user terminals 1, 2, and 3 are collectively referred to as the user terminal 100.

The user accesses the network system 20 through the user terminal 100 (S201). Then, the network system 20 grasps the unique identifier of the connected user terminal 100 (S202), grasps the connection sequence number of the minimum number that can be assigned (S203), and matches and stores the connection sequence number to the identified unique identifier. (S204).

Then, the network system 20 determines whether resource allocation is possible to the user terminal 100 (S205).

The network system 20 does not allocate resources if there are many other users having access numbers faster than the access numbers of the user terminal 100, and the amount is not enough to handle the current available resource amount. Of course, the network system 20 allocates resources when there are no or fewer previous accessors having a faster turn than the turn of the user terminal 100, and enough capacity to accommodate all the previous accessors with the current available resource amount.

The previous accessor refers to a user terminal having a fast sequence number based on the currently connected user terminal.

In step S205, if the network system 20 determines that the resource is not allocated to the user terminal 100, the network system 20 calculates a waiting time to be provided to the user terminal 100 using the amount of available resources and the number of previous accessors. (S206). The wait time becomes shorter as the amount of available resources or the number of previous accessors is short, and as the amount of available resources is small or the number of previous accessors is longer.

In addition, the network system 20 provides a waiting notification message including the calculated waiting time to the user terminal 10 (S207).

Then, the user terminal 100 receives the standby notification message and at the same time terminates the connection with the network system 20 (S208), counts the waiting time (S209), and at the time when the waiting time count ends, the network system ( Reconnect to 20) (S201).

The wait time count means a time count from the time point at which the wait time is received to the wait time. For example, if the waiting time is 10 seconds, the waiting time count is a time count from 10 seconds after the reception time.

On the other hand, if the network system 20 determines that the resource allocation is possible to the user terminal 100 in the determination (S205), allocates the resource to the user terminal 100 (S210). Then, the user terminal 100 uses the service using the allocated resources (S211).

On the other hand, if the user terminal 100 does not connect within the valid time set from the first time point or the first time point when the waiting time ends, the network system 20 deletes the matching access sequence number corresponding to the user terminal 100.

Next, another example of achieving the service with reference to FIG. 1 will be described with reference to FIG. 3. The following description with reference to FIG. 3 is an example to which the present invention is applied. 3 is a flowchart illustrating a data in a service environment to which a waiting table management method according to an exemplary embodiment of the present invention is applied.

The user first accesses the network system 20 through the user terminal 100 and requests for issuance of the access sequence (S201). Here, since the access sequence has a form provided to the user terminal, it is referred to as a "wating number ticket" below.

The first connection is a connection of the user terminal 100 having no waiting table to the network system 20, hereinafter referred to as a connection requesting the waiting table to the network system 20. The wait table is a wait identifier and includes number information indicating the access sequence number.

The network system 20 recognizes the first connection of the user terminal 100 as a request for issuing a waiting table and provides a waiting table to the user terminal 100 (S302).

When the user terminal 100 receives the waiting table (S203), it connects to the network system 20 through the second connection (S304). The second connection means that the user terminal 100 accesses the network system 20 using the waiting table, hereinafter referred to as a connection requesting resource allocation to the network system 20.

The network system 20 then grasps the waiting sequence number with the received waiting table and determines the amount of available resources (S305). Then, the network system 20 determines whether the resource can be allocated to the user terminal 100 through the grasp of step S305 (S306).

The network system 20 does not allocate resources if there are many other users whose turn numbers (ie, numbers) are faster than the waiting table of the user terminal 100, and the number is not enough to process the current available resource amount. Of course, the network system 20 allocates resources when there are no users (or user terminals) having a waiting table that is faster than the waiting table of the user terminal 100, and enough capacity to accommodate all previous accessors with the current available resource amount. .

The previous accessor refers to a user having a waiting table which is faster than any waiting table.

In step S305, if the network system 20 determines that a resource cannot be allocated to the user terminal 100, the network system 20 calculates a waiting time to be provided to the user terminal 100 using the available resource amount and the number of previous accessors. (S307). The wait time becomes shorter as the amount of available resources or the number of previous accessors is short, and as the amount of available resources is small or the number of previous accessors is longer.

The network system 20 provides the calculated waiting time to the user terminal 10 (S308).

Then, the user terminal 100 receives the waiting time and at the same time terminates the connection with the network system 20 (S309), counts the waiting time, and at the end of the waiting time counting, the second connection to the network system 20 again. To make a resource allocation request (S304).

The wait time count means a time count from the time point at which the wait time is received to the wait time. For example, if the waiting time is 10 seconds, the waiting time count is a time count from 10 seconds after the reception time.

On the other hand, if the network system 20 determines that resource allocation is possible to the user terminal 100 in the determination (S306), the network system 20 allocates the resource to the user terminal 100 (S311). Then, the user terminal 100 uses the service using the allocated resources (S312).

Hereinafter, a network system for achieving an example of the present invention described with reference to FIG. 3 will be described with reference to FIG. 4. 4 is a block diagram of a network system according to an embodiment of the present invention.

As shown in FIG. 4, the network system 20 according to the embodiment of the present invention includes a transaction server 200, a service controller 300, and a service server 400.

The transaction server 200 is in charge of the interface with the user terminal 100, permits the connected user terminal 100 to access the service server 400 or instructs the user to wait for the connection. The transaction server 200 includes the connection identifier in the standby notification message and provides the user terminal 100 with the connection notification message to notify the user to reconnect when the user terminal 100 reconnects. The connection identifier may be an identifier indicating the connection to the transaction server 200 or may be address information.

 The transaction server 200 grasps the waiting table (or access sequence number) when the user terminal 100 connects. In this case, when the waiting table is identified, the waiting table is assigned to the user terminal 100. When the waiting table is identified, the waiting table is stored and managed by matching with the unique identifier of the user terminal 100. In addition, the transaction server 200 determines whether the user terminal 100 is within a resource allocation range based on the issued waiting table (or access sequence number), and determines access permission. The waiting time is calculated and provided.

When the transaction server 200 provides the waiting table (or access number) to the user terminal 100, the transaction server 200 registers (adds) the waiting table (or access number) to the waiting list.

In this case, the waiting list has an example as shown in FIG. 11.

11 is a diagram illustrating a waiting list according to an embodiment of the present invention. As shown in Fig. 11, the waiting list includes a field in which a waiting table (or access number) is recorded and a field in which a waiting table (or access number) is registered corresponding to the waiting table (or access number).

The wait list is registered with a wait table (or access sequence number) sorted by size and has a fixed size. In other words, the waiting list has a fixed number of waiting tables (or connection numbers) registered in the waiting list. The reason for keeping the size of the waiting list fixed is to prevent overhead. This is because if the size of the waiting list is not fixed size, when a large number of user access requests enter the waiting list instantly, the waiting list size becomes so large that a lot of overhead occurs when sorting or deleting.

In the case of using the fixed size waiting list, the waiting list addition for a new user terminal may occur while the waiting list is full. In this case, the present invention calculates and provides only the waiting time to the user terminal without registering (adding) the waiting table of the new user terminal to the waiting list.

In addition, when the transaction server 200 grants access to the user terminal 100, the transaction server 200 registers (adds) a wait list (or access sequence number) of the user terminal 100 to the allocation list.

In this case, the allocation list has an example as shown in FIG. 12.

12 is a diagram illustrating an allocation list according to an embodiment of the present invention. As shown in Fig. 12, the allocation list includes a field in which a waiting table (or access number) is recorded and a field in which a waiting table (or access number) is registered corresponding to the waiting table (or access number). This allocation list is a list in which a waiting table (or access sequence number) is registered regardless of size and has a variable size.

The service controller 300 adjusts the number of user terminals 100 that can access the resources of the service server 400 according to the resource usage state of the service server 400 that is variable in connection with the operation of the transaction server 200. To control the operation of the transaction server 200 to. To this end, the service controller 300 designates the range of the waiting table (or access sequence number) that can be issued to the transaction server 200, and calculates and accesses the waiting time in consideration of the resource usage status of the service server 400 and the number of previous users. Provide basic data for permits.

The service server 400 allocates resources to the user terminal 100 granted access by the transaction server 200 and provides a service requested by the user terminal 100.

On the other hand, an embodiment of the present invention shown in Figure 4 is to separate each configuration (200, 300, 400) independently, the user to separate the connection between the transaction server 200 and the service server 400 Although described, the present invention is not limited thereto.

That is, the present invention may allow the transaction server 200, the service controller 300, and the service server 400 to be integrated. That is, the service server 400 may be configured to include the function of the transaction server 200 and the function of the service controller 300 in the service server 400. In this case, for example, the access permission provided to the user terminal 100 may be replaced by internal signal processing between the function of the transaction server and the function of the service server.

Hereinafter, a standby table management method according to an embodiment of the present invention based on FIG. 4 will be described in detail with reference to FIG. 5. 5 is a flowchart illustrating an operation of a network system according to an exemplary embodiment of the present invention.

The user terminal 100 requests a connection to the service server 400 in order to use a service provided by the service server 400. Accordingly, the service server 400 instructs the user terminal 100 to access the transaction server 200 because the user terminal 100 is not authorized to access the transaction server 200.

Then, the user terminal 100 makes a first connection to the transaction server 200 (S501).

As the user terminal 100 makes the first connection, the transaction server 200 determines whether there is a waiting table that can be issued in the registered waiting table block (S502). If it is determined in step S502 that the transaction server 200 is not capable of issuing a waiting table, the transaction server 200 requests a new waiting table block from the service controller 300 (S503), and receives and registers a new waiting table block from the service controller 300 ( S504).

However, if it is possible to issue the waiting table by the determination (S502), the transaction server 200 issues the waiting table with the fastest order (that is, number) among the waiting tables that can be issued in the registered waiting table block to the user terminal 100 (S505).

Here, the waiting block is a collection of waiting tables arranged in a sequence. For example, the waiting table block is a collection of waiting tables 1 to 100, or a collection of waiting tables 300 to 500.

When the user terminal 100 receives the waiting table, the user terminal 100 makes a second connection and presents the waiting table to the transaction server 200 (S506).

Accordingly, the transaction server 200 determines whether the connection is possible by identifying the allowable ID for which the number (that is, the sequence number) of the waiting table presented by the user terminal 100 is set (S507). Allowed ID here is the largest waiting table that can be accessed.

Of course, the transaction server 200 will determine that the connection is possible if the number of the waiting table is smaller than the allowed ID, otherwise it will determine that it is not accessible.

If the transaction server 200 determines that the connection is not possible in the determination S507, the transaction server 200 registers (adds) the waiting table to the waiting list (S508), and waits time corresponding to the amount of available resources and the number of previous users based on the waiting table. To calculate and notify the user terminal 100 (S509).

When receiving the waiting time, the user terminal 100 terminates the connection with the transaction server 200 (S510), counts the waiting time (S511), and makes a second connection once again when the waiting time ends. Request for permission (S506).

On the other hand, if it is determined in step S507 that the connection is possible, the transaction server 200 registers (adds) the waiting table to the allocation list (S512), and transmits a message informing the user terminal 100 of the permission to connect. (S513).

Accordingly, the user terminal 100 accesses the service server 400 using the received access permission message, and the service server 400 confirms that the access of the user terminal 100 is an access according to the access permission message. The user terminal 100 can use the service through the allocated resource by allocating the resource to 100 (S514).

In this way, when the user terminal 100 uses the service using the resource, the user terminal 100 notifies the transaction server 200 of the service using the service (S515).

The transaction server 200 monitors whether each user terminal 100 corresponding to the waiting lists registered in the allocation list is using the resource or not (S517). In this case, the monitoring is to determine whether a notification message is received from the user terminal 100 within a set time.

In the monitoring operation S517, when the notification message is received within the set time from the user terminal 100, the transaction server 200 determines that the resource is continuously used and maintains the information of the current allocation list.

On the other hand, in the monitoring operation S517, the transaction server 200 determines that the user terminal 100 has finished using the resource when the notification message is not received from the user terminal 100 within a set time (S518). In this case, the transaction server 200 removes (delete) the waiting table of the user terminal 100 that has finished using the resource from the allocation list (S519).

Meanwhile, the transaction server 200 provides the wait list and the assignment list to the service controller 300 at set time periods (S520, S523, and S526).

Here, the transaction server 200 may provide the wait list and the assignment list to the service controller 300 when the wait table is registered in the wait list, the wait table is registered in the assignment list, or when any wait table is deleted from the assignment list. Can be.

When the service controller 300 receives the waiting list and the allocation list from the transaction server 200, the service controller 300 analyzes the resource usage state and the received waiting list and the allocation list, which are identified from the service server 400, to make the standby table accessible. The determination is made as to whether or not the determined waiting table is determined as an allowable ID (S521, S524). The method of determining the grant ID will be described in detail below.

When the permission ID is determined in this way, the service controller 300 provides the determined permission ID to the transaction server 200 (S522 and S525). Then, the transaction server 200 deletes the previously registered permission ID and registers the permission ID received from the service controller 300.

In the above, the service controller 300 provides an average empty resource per second (EPS) to the transaction server 200 along with the allowable ID. The service controller 300 calculates an EPS for each set cycle time, and the transaction server 200 calculates a waiting time using the EPS.

Hereinafter, the service controller 300 illustrated in FIG. 4 will be described in more detail with reference to FIG. 6. FIG. 6 is a block diagram according to an exemplary embodiment of the service controller illustrated in FIG. 4.

As shown in FIG. 6, the service controller 300 includes a local interface 310, a wait table block issuing unit 320, an allowable ID calculating unit 330, and a resource change monitoring unit 340.

The local interface 310 is responsible for the interface between the transaction server 200 and the service server 400.

When the waiting block block issuing unit 320 receives a request for a new waiting block from the transaction server 200, the waiting block block issuing unit 320 generates a new waiting block block having a predetermined size and provides it to the transaction server 200. When providing a new wait block, the wait block block issuing unit 320 recognizes the information of the wait block previously provided to the transaction server 200, and makes a transaction by using a wait block that is continuous to the wait table block provided as the new wait block. It provides to the server 200. For example, if the previously provided waiting block has a waiting table 1 to 100, the waiting block block issuing unit 320 provides the waiting server blocks 101 to 200 as a new waiting block to the transaction server 200 as a new waiting block. do.

The allowable ID calculator 330 calculates the allowable ID using the wait list, the allocation list, and the resource use state of the service server 400 received from the resource change monitor 340.

Here, the method of calculating the allowable ID made by the allowable ID calculator 300 will be described in more detail.

The allowable ID calculator 330 first calculates an EPS for calculating the allowable ID.

There are several ways to calculate EPS.

In a first manner, the allowable ID calculation unit 330 examines the allocation list every set cycle time (for example, 1 second, 2 seconds, 5 seconds, and the like) to determine the number of waiting tables that have finished using resources and exited. In other words, how many waiting tables have been deleted from the allocation list during the set cycle time is determined. If the number of waiting tables thus identified is A and the set cycle time is Ts, EPS can be expressed as A / Ts.

In a second manner, the EPS may include not only the allocation list but also the number of user terminals which exited before receiving permission to access the service server 400 using the waiting list. In this case, the allowable ID calculation unit 330 divides the sum of the total number of waiting tables deleted from the waiting list and the total number of waiting tables deleted from the allocation list by the average per second as EPS.

When the EPS is obtained, the allowable ID calculation unit 330 identifies the currently available resources and calculates an allowable range by adding the calculated EPS to the number of user terminals that can be accommodated as the available available resources.

The allowable ID calculator 330 then sets the wait table having the largest order in the allowable range as the allowable ID in the wait list. Here, the allowable ID calculation unit 330 does not increase the allowable range randomly and sets an upper limit that can be increased at one time to prevent a sudden change in value.

The allowable ID calculator 330 calculates the EPS and the allowable ID and provides the same to the transaction server 200.

The resource change monitoring unit 340 monitors the resource of the service server 400 and monitors a change above or below a set value. That is, the resource change monitoring unit 340 notifies the allowable ID calculation unit 330 when the resource of the service server 400 exceeds the first set value compared to the number of user terminals registered in the allocation list. To reduce the range. On the contrary, the resource change monitoring unit 340 notifies the allowable ID calculator 330 when the resource of the service server 400 is less than the second set value compared to the number of user terminals registered in the allocation list. Increase the allowable range.

Next, the transaction server 200 of the present invention will be described with reference to FIG. FIG. 7 is a block diagram illustrating an embodiment of the transaction server illustrated in FIG. 4.

As shown in FIG. 7, the transaction server 200 includes a user interface 201, a local interface 202, a reception information checking unit 203, a waiting table issuing unit 204, a connection approval unit 205, and a waiting time. Calculating unit 206, resource usage monitoring unit 207, waiting table block storage unit 208, standby list management unit 209, basic information storage unit 210, allocation list storage unit 211, issuance status notification unit ( 212) and an assignment list management unit 213.

The user interface 201 is responsible for the interface with the user terminal 100, and the local interface unit 202 is responsible for the interface with the service controller 300.

The reception information identifying unit 203 analyzes a message received from the user interface unit 201 and delivers the received message to the internal configuration to process the message according to the analysis. Herein, the message from the user interface unit 201 includes a message according to a first connection, a message according to a second connection, and a notification message indicating resource usage.

When a message according to the first connection is received, the waiting table issuing unit 204 issues a waiting table to the corresponding user terminal 100 using a fixed sized waiting table block stored in the waiting block block storage unit 208, and waits for the issued waiting table. Add to list At this time, the wait table includes a unique identifier for identifying the transaction server 200. This unique identifier allows the user terminal 100 to reconnect to the transaction server to which it initially connected.

The waiting table issuing unit 204 requests a new waiting table block from the service controller 300 when all of the waiting tables of the waiting table blocks stored in the waiting table block storage unit 208 are used.

The wait list storage unit 209 does not store the wait list when a waiting table having a value larger than the maximum value (highest number) of the wait table entered in the wait list is entered when the fixed size of the wait list is full.

The connection approval unit 205 receives the message according to the second connection and compares the waiting table included in the second connection message with the permission ID stored in the basic information storage unit 210 to determine whether to permit the connection. At this time, the connection approval unit 205 permits the connection if the number of the waiting table is smaller than the number of the allowed ID. On the other hand, when the transaction server 200 is integrated with the service server 400, the connection approval unit 205 functions to allocate resources to the user terminal instead of determining the connection permission.

The waiting time calculating unit 206 operates under the control of the connection approval unit 205 and calculates the EPS stored in the basic information storage unit 210 based on the waiting time corresponding to the waiting table number of the user terminal 100 which is not permitted to access. The calculated waiting time is provided to the user terminal 100. For example, if the waiting table number of the user terminal 100 is 2000, the allowable ID is 1000, and the EPS is 50, the waiting time is 20 seconds through the equation (2000-1000) / 50.

The resource usage monitoring unit 207 monitors whether or not the notification message sent from the user terminal 100 is received, and notifies the allocation list manager 213 if there is a user terminal 100 that has not received the notification message within a set time. .

The allocation list management unit 213 deletes the waiting table of the corresponding user from the waiting list when the connection approval (or resource allocation approval) is made by the connection approval unit 205, registers the registration list in the allocation list, and the resource usage monitoring unit 207. Delete the waiting table of the user terminal received from the assignment list.

The wait block storage unit 208 stores a wait table block of a fixed size provided from the service controller 300. The waiting table block stored in the waiting table block storage unit 208 is managed by displaying a previously issued waiting table and an available waiting table separately.

The standby list storage unit 209 stores the standby list having a fixed size.

The basic information storage unit 210 stores basic information necessary for access approval. The basic information is a permission ID and an EPS, and is periodically provided by the service controller 300. When the basic information storage unit 210 receives the basic information from the service controller 300, the basic information storage unit 210 deletes the previously stored basic information and stores the currently received basic information. The allocation list storage unit 211 stores an allocation list having a variable size. Save it.

The issuing status notification unit 212 collects the waiting list and the allocation list stored in the waiting list storage unit 209 and the allocation list storage unit 211 for each set cycle time, and the service controller 300 through the local interface unit 202. To provide.

Hereinafter, a waiting table issuing method according to an embodiment of the present invention will be described with reference to FIG. 8. FIG. 8 is a diagram for describing a method of issuing a waiting table according to an embodiment of the present invention based on FIG. 4.

The embodiment of the present invention illustrated in FIG. 8 is a case where the issuance of waiting table is achieved by using one transaction server 200.

The service controller 300 has a plurality of waiting table blocks (A, B, C, etc.) having the same size, and provides only one of the waiting table blocks to the transaction server 200. In FIG. 8, the service controller 300 provides the wait table block B to the transaction server 200.

The same size of wait table blocks means that each wait block has the same number of wait tables. For example, as shown in FIG. 8, the wait table block A has a total of 100 wait table blocks from 0 to 99, and the wait table block B has a total of 100 wait table blocks from 100 to 199.

When the transaction server 200 receives one waiting table block, the transaction server 200 provides the waiting table in the received waiting table block to the user terminal 100.

If all of the waiting tables in the waiting table block are provided to the user terminal 100, the transaction server 200 requests a new waiting table block from the service controller 300. Then, the service controller 300 provides the transaction server 200 with a new wait block block as the next wait block block of the wait block of the transaction server 200. For example, if the transaction server 200 is storing the wait table block B, the service controller 300 provides the wait table block C to the transaction server 200 as a new wait table block.

As a result, the transaction server 200 can provide the user terminal 100 newly connected with the waiting table in sequence in the exchange of the waiting table block.

Next, a waiting table issuing method according to another embodiment of the present invention will be described with reference to FIG. 9. FIG. 9 is a diagram for describing a method of issuing a waiting table according to another exemplary embodiment of the present disclosure based on FIG. 4.

Another embodiment of the present invention shown in FIG. 9 is a case where the issuance of a waiting table is achieved using a plurality of transaction servers 210, 220, and 230.

The service controller 300 has a plurality of waiting table blocks (A, B, C, etc.) of the same size, and provides only one of the waiting table blocks to each of the first to third transaction servers 210, 220, and 230. In FIG. 9, the service controller 300 provides the waiting table block B to each of the transaction servers 210, 220, and 230.

When each transaction server 210, 220, 230 receives one wait table block, the transaction server 210, 220, 230 provides the wait table in the received wait table block to the user terminal 100.

In this case, the first to third transaction servers 210, 220, and 230 divide the waiting tables of the waiting table blocks by the number of transaction servers and provide them to the user terminal 100, and sequentially issue them according to the numbers of the waiting tables. That is, the first transaction server 210 issues 100, 103, 106, ..., 199 waiting table, the second transaction server 220, 101, 104, 107, ... 197, the waiting table is issued, and the third transaction server 230 issues 102, 105, 108, ..., 198 waiting table.

 Of course, the order of the waiting table issued by each transaction server (210, 220, 230) is the connection order of the user terminal. In order to sequentially connect the user terminals to each transaction server, this may be achieved by using a load balancing device.

If one of the first to third transaction server (210, 220, 230) of the transaction server provides the user terminal 100 with all the waiting table allocated in the waiting table block, the transaction server is issued to the waiting table of the other transaction server Regardless, the service controller 300 requests a new wait table block.

The service controller 300 then provides each transaction server 210, 220, 230 as a new wait block block to the next wait table block of the wait block of each transaction server 210, 220, 230. For example, if each transaction server 210, 220, 230 is storing a wait table block B, the service controller 300 converts the wait table block C into a new wait table block. To provide.

When each transaction server 210, 220, 230 receives a new wait block from the service controller 300, it stops issuing a wait table in the currently used wait block and starts issuing a wait table in the new wait block.

If a new fourth transaction server (not shown) is added in addition to the three transaction servers 210, 220, and 230, the newly added transaction server requests the service controller 300 for a new queue block, and thus the service controller. 300 provides a new queue block to each of the four transaction servers. Of course, in this case, each of the four transaction servers stops issuing the queue in the queue block currently in use and starts issuing the queue in the new block.

Hereinafter, a method of allowing access to the service server (that is, resource allocation) will be described with reference to FIG. 10. FIG. 10 is a diagram for describing a method for allowing resource allocation according to an embodiment of the present invention based on FIG. 9.

The service controller 300 collects wait lists collected from each transaction server 210, 220, and 230, identifies waiters, and collects allocation lists to determine available resource amounts to set allowable IDs. In FIG. 10, the allowable ID is 120.

Accordingly, each transaction server 210, 220, 230 sets the allowable ID to 120 according to the instruction of the service controller 300.

In the state where the allowable ID is set, when the user terminal 100 having a unique number table is connected to the transaction server 210, 220, 230, respectively, each transaction server 210, 220, 230 is connected to the user terminal 100. ), Compare the number table with the allowable ID.

Each transaction server 210, 220, 230 grants access when the number table of the user terminal 100 is smaller than the allowed ID through comparison between the number table of the user terminal 100 and the allowable ID, and the number table of the user terminal 100. If is greater than the allowed ID, the wait time is calculated to indicate the wait.

For example, the transaction server 210 grants access to the first user terminal since the permission ID is 120 when the first user terminal having the number 105 is connected. When the second user terminal having the 112 number table is connected, the transaction server 210 grants access to the first user terminal because the allowed ID is 120. However, the transaction server 210 instructs each user terminal to wait since the allowed ID is 120 when the user terminal having the 120 or more number table is connected.

The transaction server 210, 220, 230 deletes the number table allowed to access from the waiting list and adds it to the allocation list.

Meanwhile, the present invention may enable preferential resource allocation to a specific user terminal while performing the connectionless connection management method for the general user terminal described above. To this end, the present invention stores the unique identification information (IP address, mobile phone number, ID / password, etc.) for a specific user terminal for the recognition of the specific user terminal, resource allocation (or service if the specific user terminal is connected) Permission to connect to the server). That is, unlike a general user terminal, a specific user terminal is immediately allocated when an available resource occurs without a separate waiting time.

In addition, the above-described method for issuing and retrieving a waiting table according to an embodiment of the present invention has been described with reference to an embodiment applied to a connection management method in which a user terminal reconnects after disconnecting for a waiting time, but the present invention is not limited thereto. . The method for issuing and retrieving a waiting table according to the present invention is applicable to all cases of providing a waiting table to a user terminal requesting the use of resources.

The embodiments of the present invention described above are not only implemented by the apparatus and method but may be implemented through a program for realizing the function corresponding to the configuration of the embodiment of the present invention or a recording medium on which the program is recorded, The embodiments can be easily implemented by those skilled in the art from the description of the embodiments described above.

Although the embodiments of the present invention have been described in detail above, the scope of the present invention is not limited thereto, and various modifications and improvements of those skilled in the art using the basic concepts of the present invention defined in the following claims are also provided. It belongs to the scope of rights.

Claims (6)

What is claimed is: 1. A method of managing a waiting table in a network system that allocates resources to user terminals to enable service use.
a) checking a connection of the user terminal,
b) providing a waiting table and waiting time if the connected user terminal does not have a waiting table,
c) registering the waiting table provided to the user terminal of step (b) in the waiting list,
d) if the accessed user terminal has a waiting table but resource allocation is not possible, providing a new waiting table and waiting time to the user terminal and updating the waiting table of the user terminal registered in the waiting list with the new waiting table. ,
e) allocating resources to the user terminal if the accessed user terminal has a waiting table and resource allocation is possible;
f) deleting the waiting table of the user terminal of step e) from the waiting list and registering it in the assignment list;
g) determining whether a resource usage notification message is received within a set time from a user terminal using the resource, and
h) deleting a waiting table of the corresponding user terminal in which the resource usage notification message has not been received within a predetermined time period from the allocation list,
The waiting table indicates the order of connection to the network system, and the waiting time is a time waiting for the next connection after the user terminal is disconnected from the network system. delete The method of claim 1,
The step a) may include determining whether a waiting table can be issued in a first waiting table block including a first number of waiting tables in a series;
Issuing the waiting table in a second waiting block block including the first number of waiting tables in a sequence consecutive to the largest waiting table in the first waiting block if it is not possible to issue the waiting table in the first waiting block. Waiting table management method comprising a. The method of claim 3,
i) deleting the first waiting table from the waiting list if the user terminal that has issued the first waiting table does not make a resource allocation request within a set time. The method of claim 4, wherein
The waiting list includes a field in which a waiting table is registered and a field in which a time when the waiting table is registered, each field has a fixed size limited to a set number, and the waiting table registered is arranged in sequence according to the order. The method of claim 4, wherein
The allocation list includes a field in which a waiting table is registered and a field in which a time when the waiting table is registered is recorded, and each field is not fixed size limited to a set number and is registered in the field regardless of the order of the waiting table.

Images