KR101074848B1 - Contact management method on non-connection type - Google Patents

Abstract

The present invention relates to a connectionless connection management method in a network system that allocates resources to user terminals to enable service use. When the first user terminal detects a connection, the present invention determines whether the resource can be allocated to the first user terminal, and allocates the resource if the resource can be allocated. If the resource allocation is not possible, the first user terminal provides the first waiting time. Send a standby notification message that includes. Then, after canceling the connection with the first user terminal that provided the waiting time, by detecting the reconnection of the first user terminal waiting for the connection during the waiting time to determine whether resource allocation is possible to the first user terminal reconnected If the resource allocation is possible, the resource is allocated. If the resource allocation is not possible, the standby notification message including the second waiting time is transmitted to the first user terminal to disconnect and reconnect during the second waiting time.

Description

Contact management method on non-connection type

The present invention manages access to a user terminal for resource management of a network system. In particular, the present invention relates to a connectionless connection management method that enables a network system to provide a stable service with limited resources even when a user terminal requesting resource allocation is congested.

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 connectionless connection management method that enables a service processor to be stably executed without burdening a network system even when a user who connects beyond a limit that can be processed by a limited resource is connected.

According to an aspect of the present invention, there is provided a connectionless connection management method in a network system that enables service usage by allocating resources to a user terminal. The method includes detecting a connection of a first user terminal, allocating a resource if a resource can be allocated to the first user terminal, and a standby including a first waiting time to the first user terminal if resource allocation is not possible. Transmitting a notification message, terminating the connection with the first user terminal providing the waiting time, detecting a reconnection of the first user terminal waiting for the connection during the waiting time, and the reconnecting first If the resource allocation is possible to the user terminal and the resource allocation is not possible, the step of transmitting a standby notification message including a second waiting time to the first user terminal.

According to the above-described embodiment, the present invention enables to protect a limited resource and provide a smooth service to the user by maintaining the number of users accessing the limited resource at a certain level when the user requests a congestion.

1 is a conceptual diagram for explaining the present invention.
2 is a data flow diagram illustrating a connectionless connection management method according to a first embodiment of the present invention.
3 is a data flow diagram illustrating a connectionless connection management method according to a second embodiment of the present invention.
4 is a block diagram of a network system according to an embodiment of the present invention.
5 is a data flowchart of a connectionless connection management method according to a second embodiment of the present invention based on FIG. 4.
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 connectionless connection management method according to an embodiment of the present invention will be described with reference to the accompanying drawings. FIG. 1 is a conceptual diagram for explaining the present invention. An example of three users will be described. Of course, the user who is the service target of the present invention is not limited to the number, and the service target is all user terminals that can be connected to the network system of the present invention.

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 transmits a waiting notification message including 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. . 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 has a role of indicating standby for connection to the network system 20.

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, 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.

In view of the above, the present invention allocates resources to user terminals in the order of access, and causes the user terminal to terminate the connection between the network system 20 in a situation in which resources are insufficient. 20) to be protected.

On the other hand, for the present invention, the network system 20 should grasp the connection order of the user terminal in order to calculate the waiting time or allocate resources.

To this end, when the user terminal accesses, the network system 20 grasps a unique identifier (eg, an IP address, a mobile phone number, etc.) of the accessed user terminal, and matches the identified unique identifier with a minimum connection sequence number that is not internally duplicated. (E.g., 1, 10, 234, 999, etc.). Here, the minimum access sequence number that does not overlap means the lowest number among the access sequence numbers that are not assigned to other user terminals, and means that the access sequence number is assigned according to a predetermined rule. The constant rule means a rule that increases by 1, such as 1, 2, 3, or a rule that increases by 2, such as 1, 3, 5, 7, 9, and 2, 4, 6, 8.

 In addition, the network system 20 knows the access sequence of the user terminal by identifying the unique identifier of the user terminal and the access sequence matched with the unique identifier when the user terminal is connected, thereby allocating resources according to the access sequence. do.

Of course, the network system 20 may include the access sequence number in the standby identifier and provide the access sequence to the user terminal, and provide the access sequence number to the network system 20 when the user terminal reconnects.

On the other hand, the present invention can lengthen the waiting time long enough to allow the network system 20 to secure enough resources. However, in this case, the more late users are connected, the longer the waiting time becomes and the user may leave without using the service. In addition, the present invention can shorten the waiting time so that the user can use the resource as soon as the network system 20 secures the resource. However, in this case, if the network system 20 does not secure resources in a short time, the network system 20 needs to handle frequent access of the user, and repeatedly calculate the waiting time for each frequent access and provide the user with the problem.

Therefore, the present invention needs to be able to allocate resources to the user terminal with a minimum waiting time while reducing the number of reconnections.

Hereinafter, a connectionless connection management method according to a first embodiment of the present invention for achieving the concept of the present invention with reference to FIG. 2 will be described with reference to FIG. 2. 2 is a data flow diagram illustrating a connectionless connection management method according to a first embodiment of the present invention. 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, a connectionless connection management method according to a second embodiment of the present invention for achieving the concept of the present invention with reference to FIG. 3 will be described with reference to FIG. 3 is a data flow diagram illustrating a connectionless connection management method according to a second embodiment of the present invention.

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 "wait table" 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 according to an embodiment for implementing the first and second embodiments of the present invention 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.

Meanwhile, according to an embodiment of the present invention illustrated in FIG. 4, the components 200, 300, and 400 are separated from each other independently, so that a user needs to separate the connection between the transaction server 200 and the service server 400. However, 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, the present invention will be described based on the second embodiment of the first and second embodiments of the present invention. Those skilled in the art will be able to easily implement the first embodiment of the present invention through the second embodiment of the present invention. This is because the method of managing the connection order of the user terminal in the first embodiment of the present invention is different from the second embodiment of the present invention except that it is different from the second embodiment of the present invention.

5 is a view illustrating a connectionless connection management method according to a second embodiment of the present invention based on the configuration of the user terminal 300 and the network system 20 shown in FIG. 4 (200, 300, 400). It will be described in more detail. 5 is a data flowchart of a connectionless connection management method according to a second embodiment of the present invention based on FIG. 4.

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 unit 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 calculates the order difference between the smallest waiting table registered in the waiting list and the largest waiting table registered in the allocation list for each set cycle time, and divides the sequence number by the set cycle time to average wait tables per second. Determined by treated water (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 allowed 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 calculation unit 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, a transaction server 200 for achieving the second embodiment 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. Calculation unit 206, resource usage monitoring unit 207, waiting table block storage unit 208, standby list storage unit 209, basic information storage unit 210, allocation list storage unit 211 and issuing status notification Section 212.

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 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.

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 has been received, and determines that the resource usage is completed for the user terminal 100 that has not received the notification message within a set time. Delete the user's queue from.

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 waiting list storage unit 209 stores a waiting list having a fixed size, and adds or deletes the waiting table to the waiting list according to the instruction of the waiting table issuing unit 204. At this time, the waiting list storage unit 209 sorts the added waiting table in numerical order and stores the waiting table in the waiting list.

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 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, adds a waiting table to the allocation list according to the instruction of the connection approval unit 205, and adds the waiting list to the allocation list according to the instruction of the resource usage monitoring unit 207. Delete the corresponding queue.

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.

* Eventually, the transaction server 200 can provide the user terminal 100 newly connected with the waiting table in consecutive order by the exchange of such waiting table blocks.

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.) having the same size, and provides only one of the waiting table blocks to each transaction server 210, 220, 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.

At this time, each of the transaction server 210, 220, 230 divides the waiting table of the waiting table block by the number of transaction servers to provide to the user terminal 100, it is issued sequentially according to the number of the waiting table. 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.

Then, the service controller 300 provides each transaction server 210, 220, or 230 as a new wait block to the next wait block of the wait block of the first to third transaction servers 210, 220, and 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 first transaction server 210 grants access to the first user terminal because the permission ID is 120 when the first user terminal having the number 105 number is connected. When the second user terminal having the 112 number table is connected, the first transaction server 210 grants access to the first user terminal because the allowed ID is 120. However, the first 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 first, second, and third transaction servers 210, 220, and 230 delete the number tables allowed to access from the waiting list and add them 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.

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.

100: user terminal 200: transaction server
300: service controller 400: service server

Claims (3)

In the connectionless connection management method in a network system, such as a Web (WEB) server or a WAP (WAP) server to allocate resources to the user terminal to use the service,
a) detecting a connection of the first user terminal,
b) allocating resources if the resource allocation is possible to the first user terminal, and transmitting a standby notification message including a first waiting time to the first user terminal if the resource allocation is not possible;
c) terminating the connection with the first user terminal that provided the standby notification message;
d) detecting reconnection of the first user terminal waiting for access during the waiting time included in the waiting notification message;
e) allocating resources if the resource access is possible for the reconnected first user terminal and transmitting a standby notification message including a second waiting time to the first user terminal if resource allocation is not possible; and
f) disconnecting the first user terminal and detecting whether to reconnect with the first user terminal after the second waiting time. The method of claim 1,
And wherein at least one of the first and second wait times is a default value. The method of claim 1,
At least one of the first and second wait times is a value calculated in consideration of a resource usage state of the network system and a connection sequence number of the first user terminal.

Images