KR100803854B1 - Method of providing a reliable server function in support of a service or a set of services - Google Patents

Abstract

The present invention relates to a method for providing a reliable server function for supporting a service such as an Internet-based application, wherein the server function is provided by a server pool (SP) having one or more pool elements (PE1, PE2), each pool. Elements PE1 and PE2 may support a service or set of services. By transmitting state information related to the operational state of the one or more pool elements PE1 and PE2 from the name server NS to the full user PU, the performance, reliability and usefulness of the server function is improved in existing methods. .

Description

METHOOD OF PROVIDING A RELIABLE SERVER FUNCTION IN SUPPORT OF A SERVICE OR A SET OF SERVICES}

The present invention is directed to a method for providing reliable server functionality in supporting a service or set of services, such as Internet-based applications.

R. Stewart et al .: << Aggregate Server Access Protocol >> Internet Dratf, [Online] 9 June 2004 (2004-06-09), pages 1-43, XP002308317 IETF Retrieved from the Internet: URL: http: // www. watersprings.org/pub/id/draft-ietf-rserpool-asap-09.txt>[retrieved on 2004-11-30], together with the Endpoint Name Resolution Protocol (ENRP), allows the Aggregate Server Access Protocol (ASAP) to It is described to provide a high availability data transmission mechanism in a network. ASAP uses a name-based addressing model that separates logical communication endpoints from IP address (s), thus effectively removing the binding between the communication endpoints and their physical IP address (s) that normally constitute one point of failure.
Q.Xie et al .: << Rserpool Redundancy-model Policy >> Internet Draft, [Online] 9 June 2004 (2004-06-09), pages 1-43, XP002308317 IETF Retrieved from the Internet: URL: http: // www .watersprings.org / pub / id / draft-ietf-rserpool-asap-09.txt > [retrieved on 2004-11-30]) defines the Rserpool Redundancy-model Member Selection Policy parameters and their procedures. The policy is flexible and is designed to be able to support the wide range of enhanced redundancy models found in some high flexibility systems. The design uses scalability in Rserpool poll load sharing policy.
US 2003/0101258 A1 discloses a method for monitoring replica servers in a networked computer system, where each server in the system has a replica partner vector table containing status information about other servers in the system. Have The replica partner vector table includes data fields for storing the update sequence number and time stamp information identifying the latest update time and / or the time of the latest successful replication attempt for each replica server in the system. After each successful copy, the server updates the entries in the replica partner vector to reflect the updated USN and timestamp information. A replica monitoring method evaluates the USN and timestamp entries in a replica partner vector table to determine when any servers in the system are delayed. If the monitoring method detects that any server in the system is being delayed, an alert is generated and users and / or network administrators are informed of the problem.
In order to increase the usability and reliability for accessing server based functions, such as services provided through Internet based applications, it has been highly preferred to provide a pool of servers on behalf of only one server. Each server in a server pool, called pool elements, can support the requested service or set of services.

In order to support the high performance, usability and scalability of the application, it is necessary to keep track of which servers are in the pool and are able to receive requests and how the client binds to the desired server. These topics are discussed in the Internet Engineering Task Force (IETF) Working Group "Reliable Server Pooling" called the RSerPool Working Group. The architecture of reliable server pooling is standardized within the working group and described, for example, in Tuexen et al., "Architecture for Reliable Server Pooling," <draft-ietf-rserpool-arch-0.7txt>, October 12, 2003. See trusted server pooling fault-tolerant platform.

RSerPooL defines three kinds of architectural elements:

Pool elements PE: servers providing the same service in the pool;

Full users (PUs): clients served by PEs;

Name Servers (NS): Servers that provide resolution services to PUs and monitor the state of PEs.

In RSerPooL, pool elements are grouped in any pool. Any pool is identified by a unique pool name. To access the pool, the pool user consults a name server.

1 schematically illustrates a known RSerPooL architecture. Before sending data to the pool (identified by the pool name), the pool user sends a name resolution query to the name (or ENRP, see below) server. The ENRP server resolves the full name to the transport addresses of the PEs. Using this information, the PU can select the transport address of the PE to which to send data.

RSerPooL includes two protocols: aggregate server access protocol (ASAP) and endpoint name resolution protocol (ENRP). ASAP uses a name-based addressing model that separates logical communication endpoints from its IP address (es). Name servers use ENRP to communicate with each other to exchange information and updates about server pools. An instance of an ASAP (or ENRP) running on a given entity is referred to as the ASAP (or ENRP) endpoint of that entity. For example, an ASAP instance running on a PU is called an ASAP endpoint of the PU.

Each time a PU sends a message to a pool containing one or more PEs, the ASAP endpoint of the PU must select one PE among the PEs in the pool as the receiver of the current message. The selection is performed in the PU according to the current server selection policy (SSP). Four basic SSPs are currently being discussed for use under ASAP: Round Robin, Least Used, Least Used With Degradation, and Weighted Round Robin.RRStewart, Q.Xie: Aggregate Server Access Protocol (ASAP), <draft- ietf-rserpool-asap-0.8.txt> (October 21, 2003).

The simple exemplary sequence diagram of FIG. 2 shows the sequence of events when the ASAP endpoint of a PU performs a cache population [Stewart & Xie] for a given full name and selects a PE according to the prior art.

Cache population (update) means updating the local name cache with the latest name-to-address mapping data retrieved by the ENRP server.

The steps shown in FIG. 2 are described as follows:

S1: The ASAP endpoint of the PU sends a NAME RESOLUTION query to the ENRP server requesting all information about the given pool name.

S2: The ENRP server receives the query and finds the location of the database entry for the particular full name. The ENRP server extracts transport address information from the database entry.

S3: The ENRP server creates a NAME RESOLUTION RESPONSE containing the PE's transport addresses. The ENRP server sends a NAME RESOLUTION RESPONSE to the PU.

S4: The ASAP endpoint of the PU populates its local name cache with information of transport addresses on the full name.

S5: The PU selects one pool element among the pool elements of the server pool based on the received address information.

Ultimately, a PU accesses the selected server to use a service or set of services.

The existing fixed server selection policy uses predetermined methods to select a server. Examples of fixed SSPs are as follows:

Round Robin is a cyclical policy in which servers are selected in a sequential fashion until the initially selected server is selected again;

Weighted Round Robin is a simple extension of Round Robin. It assigns a certain weight to each server. The weight indicates the processing capacity of the server.

However, unconsciousness of dynamic system states reduces performance and reduces service reliability instead of reducing complexity. Adaptive (dynamic) SSPs determine based on changes in the system state and dynamic estimation of the optimal server. Examples of dynamic SSPs are:

Least Used SSP In the case of the SSP, the load of each server is monitored by the client (PU). Based on monitoring the load of the servers, each server is assigned a so-called policy value proportional to the load of the server. According to the Least Used SSP, the server with the lowest policy value is selected as the receiver of the current message. It is important that the SSP imply that the same server is always selected until the policy values of the servers are updated and changed.

Least Used With Degradation is the same as Least Used SSP except for one. That is, each time a server with the lowest policy value is selected from a set of servers, its policy value is increased. Thus, the server may no longer have the lowest policy value in the server set. This will cause the Least Used With Degradation SSP to become a Round Robin SSP over time. Each update to the server's policy values causes the SSP to revert to Least Used With Degradation.

The effectiveness of the dynamic SSP depends critically on the metric used to evaluate the optimal server. The survey on SSPs is mainly focused on replica web server systems. In such systems, general metrics are based on server proximity including geographic distance, number of hops for each server, round trip time (RTT) and HTTP response times. While SSPs in web systems seek to provide high throughput and small service delays, for example, session control protocols such as SIP process messages of smaller size (500 bytes on average). Thus, throughput is not a critical metric as in web systems. As far as I know, SSPs are not extensively investigated, for example using session control systems.

In view of the prior art described, an object of the present invention is to propose a method for providing a server function in supporting a service or a set of services such as Internet-based applications, wherein the server function is provided by a server pool having one or more pool elements. Each of the full elements may support a service or set of services, where reliability and usefulness of server functionality is improved over existing methods, and an object of the present invention is also to provide a name server and a full user device implementing the method. To propose.

The problem is solved by a method having a feature combination as specified in claim 1 and by a name server and a full user device as specified in claim 12 or 15 respectively.

One of the ideas underlying the present invention is the use of a message exchange between the full user and the name server to provide the full user with (additional) state information relating to the pool elements from the name server. Since the name server is a node dedicated to the server pool, the name server will generally have better information about the state of the pool elements with respect to the current state, for example based on the latest Keep-Alive-Messages.

At least the name server has additional state information, if desired, which may, when provided to the pool user, be able to determine a choice that allows enhanced performance, reliability and high availability of server functions to be performed by elements of the server pool. Provide an opportunity. In addition, the load conditions of the server pool can be optimized as well as response times.

In addition, when a message exchange is required of the full user to retrieve the transport addresses of the pool elements, it is readily possible to provide status information from the name server to the server selection module of the full user.

Thus, the present invention described herein basically proposes an RSerPool protocol extension, where a corresponding extension of the RSerPool architecture can be readily implemented on name servers and pool users.

In accordance with the present invention, nondisruptive mechanisms are distributed to full users and name servers. Full users use application layer and transport layer timers to detect transmission failures, while name servers provide a keep-alive mechanism to periodically monitor the state of the PE.

The present invention will be further described with respect to a specific server selection policy called so called Maximum Availability SSP (MA-SSP), which has been filed separately by the applicant. However, the present invention may be based on any fixed or dynamic SSP known or developed in the future, rather than being limited to the MA-SSP.

The MA-SSP is executed according to the so-called state vector. According to the MA-SSP, the state vector is size N (ie equal to the number of pool elements in a given server pool) and is defined as follows:

The particular element in the state vector represents the final known state moment of the particular PE. If the state of the last PE was on (up), the time value is stored as an unchanged state vector. If the state of the last PE was off (down), the time value is stored as a state vector with a minus sign. The MA algorithm always selects the PE with the highest value in the state vector.

로서 표시된다. 원래의 RSerPool 설명서[Tuexen 등; Stewart&Xie]에 따르면, 네임 서버는 풀 서버들의 전송 주소들을 반환한다. 예를 들면 MA-SSP를 RSerPool 아키텍쳐에 원활하게 통합하기 위해, RSerPool 확장이 특정된다. 상당히 동일한 방식으로 다른 SSP들을 위해 사용될 수 있는 상기 RSerPool 확장은 하기의 내용에서 기술된다.The ASAP endpoint of the PU completes its update of its state vector. After that, the state vector of the PU is

Is indicated as. The original RSerPool manual [Tuexen et al .; According to Stewart & Xie, the name server returns the forwarding addresses of the full servers. For example, to seamlessly integrate MA-SSP into the RSerPool architecture, the RSerPool extension is specified. The RSerPool extension, which can be used for other SSPs in a fairly identical manner, is described below.

로 표시할 것이다. 주어진 풀에 대한

벡터는 상기 풀을 위해 예약된 네임 서버 내 동일한 데이터베이스 엔트리에 저장된다. 상기 풀 내에 N 풀 엘리먼트들이 존재하는 것이 가정될 것이다.Extensions in RSerPool affect the communication between the PU and NS, that is, the ASAP endpoint of NS and the ASAP endpoint of PU. Illustrative purposes are assumed for the purpose of employing a MA algorithm in both the PU and ENRP server. The MA algorithm at the ENRP server generates a state vector for each server pool. The state vector is periodically updated by the use of an existing ASAP keep-alive mechanism [Stewart & Xie]. After that, we can

Will be displayed. For a given pool

The vector is stored in the same database entry in the name server reserved for the pool. It will be assumed that there are N pool elements in the pool.

The PU initiates cache population in two cases:

벡터를 리프레쉬하기 위해 캐쉬 파퓰레이션(갱신)을 완수하길 원한다.1) The PU has its own newest information from the name server.

We want to complete the cache population to refresh the vector.

2) The PU wants to resolve the full name.

벡터를 포함한다. ENRP 서버는 하기의 동작들을 완수한다 : In either case, the ASAP endpoint of the PU sends a NAME RESOLUTION query to the ENRP server via ASAP. The ENRP server receives the query and finds the location of the database entry for the particular pool name. The database entry is the most recent version

Contains a vector. The ENRP server performs the following actions:

1) The ENRP server extracts transport address information from the database entry.

벡터를 추출한다.2) The ENRP server must

Extract the vector.

벡터는 상기 여분의 필드에 삽입된다.3) The ENRP server creates a NAME RESOLUTION RESPONSE containing the PE's transport addresses. In addition to the transport addresses information, the name response is extended to have extra fields.

A vector is inserted into the extra field.

4) The ENRP server sends a NAME RESOLUTION RESPONSE to the PU.

벡터를 포함한다. 일단 PU가 NAME RESOLUTION RESPONSE를 수신하면, 상기 PU는 로컬 네임 캐쉬(전송 주소들 정보)뿐만 아니라 자신의

벡터를 갱신한다. PU의 ASAP

벡터의 갱신 절차는 다음과 같다 : Therefore, the NAME RESOLUTION RESPONSE is the latest version of the ENRP server.

Contains a vector. Once a PU receives a NAME RESOLUTION RESPONSE, the PU has its own name as well as its local name cache (transport address information).

Update the vector. ASAP of PU

The procedure for updating a vector is as follows:

및

는 각각

및

의 i번째 엘리먼트들이다.here

And

Are each

And

I th elements of the.

It should be noted that the above procedure is executed under the condition of synchronized time clocks in full users and name servers. This is a problem when the inter-clock drifts are excessively large. Employing a clock synchronization protocol such as Network Time Protocol (NTP) eliminates this problem.

Preferably, the protocol extension of RSerPool required to implement the present invention is simpler and easier to introduce into RSerPool. In addition, protocol extensions are transparent to the PU, ie the application layer in the client. State vectors are handled at the ASAP layer of the PU protocol stack. Thus, protocol extensions are transparent to the application layer above the ASAP layer. Each PU that supports protocol extension benefits from the performance improvements provided by the present invention.

Other aspects and advantages of the invention can be derived from the following description of embodiments of the invention with reference to the accompanying claims as well as the dependent claims.

1 is a simplified block diagram of a typical RSerPool architecture according to the prior art (discussed above),

FIG. 2 is a simplified sequence diagram illustrating message exchange between the full user and name server of FIG. 1 according to the prior art (discussed above); FIG.

3 is a sequence diagram as in FIG. 2 illustrating message exchange between a name server and a full user in accordance with an embodiment of the method of the present invention;

4 is a block diagram illustrating basic functional blocks of a name server and a full user device involved for implementing the embodiment of the present invention shown in FIG.

A schematic diagram summarizing the basic principles of the invention is shown in FIG. 3. Steps S1-S4 for cache population as defined in the present invention are as described below:

1) Sending a NAME RESOLUTION query requesting all information about a given pool name from the ASAP endpoint of the pool user (PU) to the name or ENRP server (NS).

벡터를 데이터베이스 엔트리로부터 추출한다.2) receiving the query and finding the location of a database entry for a particular full name by a name server (NS). The name server (NS) not only transmits information

Extract the vector from the database entry.

벡터가 삽입된 NAME RESOLUTION RESPONSE를 생성하는 단계. 네임 서버(NS)는 NAME RESOLUTION RESPONSE를 풀 유저(PU)에 송신한다.3) transport addresses of PEs by name server (NS) and

Generating a NAME RESOLUTION RESPONSE with a vector inserted. The name server NS sends the NAME RESOLUTION RESPONSE to the full user PU.

를 갱신하기 위해 위의 식 (1)에서 기술된 간단한 절차를 사용한다.4) Cache populate (update) the local name cache by the ASAP endpoint of the full user PU with the transport addresses information on the full name. Pool users' ASAP endpoints are state vectors

We use the simple procedure described in equation (1) above to update it.

5) selecting the particular pull element or server to which the service request is sent.

를 포함하는 별도의 필드를 갖도록 확장된다. 도 4는 풀 유저(PU) 및 네임 서버(NS)의 주요 기능 구성요소들을 나타내고, 네임 서버(NS)는 도시된 두 개의 풀 엘리먼트들(PE)을 갖는 서버 풀(SP)과 연결된다.The implementation of the method of the invention can be carried out very simply. NAME RESOLUTION RESPONSE is a state vector

It is extended to have a separate field including. 4 shows the main functional components of the pool user PU and the name server NS, which is connected to the server pool SP with the two pool elements PE shown.

The name server NS includes a pool analysis server module 10, an element status module 12, and a memory 14. Element status module 12 periodically assembles the Endpoint_Keep_Alive-message according to the IETF ASAP Protocol [Stewart & Xie] and sends the messages to each of the servers PE1, PE2.

Assuming that server PE1 is in an operational state " up " (server PE1 is ready to provide server functionality, for example for a request from client PU), server PE1 sends an Endpoint_Keep_Alive_Ack-message Responds to the Keep-Alive message from the server NS by replying to the name server NS.

Assuming another server PE2 is in an operational state "down" (server PE2 is not ready for service), server PE2 does not respond to a Keep-Alive-message from the name server NS and The local timer initiated for the Keep-Alive-message at the name server NS thus expires according to the IETF ASAP protocol.

Element state module 12 maintains a state vector stored in memory 14. The vector contains a number representing a time-stamp for each element PE1, PE2 of the pool SP, where the timestamp indicates the response processing time of each element for the Keep-Alive-message. Thus, if the Ack-message was processed at noon as measured by a clock unit (not shown) in the name server and the accuracy of the timestamp was in seconds, the Keep-Alive-ACK-message received from PE1 was sent to the module ( 12) induces the timestamp 'A8C0' (hex) to be recorded at the position of the state vector provided for the server PE1. If an Unreachable-message has been processed about one second after noon, the Unreachable-message received from PE1 is sent by module 12 to time stamp '-A8C1' (hex) at the location of the state vector provided for server PE2. Encourage them to record.

The functionality of the server module 10 is described below in more detail with respect to requests from the full user (PU). The pool user PU includes a pool analysis client module 16, a server selection module 18, a memory 20, and a server usability module 22.

The full user PU is implemented on a mobile device (not shown) capable of data and voice communication via a UMTS-network in which the server pool SP and the name server NS form part thereof. The application of the device wants to access the service provided by any of the servers in the pool (SP). In this example, the server pool (SP) is a server set or server set that implements services related to the IP Multimedia Subsystem (IMS) -domain of the UMTS network. The application is for example a SIP based application.

To request a particular service, only the full name is known to the application running on the mobile device (not shown). The application triggers the full user side of the mobile device (including the ASAP endpoint) by taking over the full name. The pool analysis client module assembles the Name_Resolution-message according to the ASAP protocol and sends it to the name server NS (step S1 in FIG. 3).

The Name_Resolution-message is received by the pool resolution server module 10 into the name server NS. The full name is extracted and the server module 10 accesses the memory 14 to extract address information stored in association with the full name. In one example, the IP-addresses of the full elements PE1, PE2 are read from the memory 14 together with the port address used to request a particular service and stored in association with the servers PE1, PE2 according to the invention. Time stamps 'A8C0', '-A8C0' are also read from memory 14. Then step S2 of Fig. 3 ends.

The server module 10 assembles a Name_Resolution_Response-message according to the IETF ASAP protocol, including a Name Resolution List with transport addresses of PE1 and PE2 as is known in the art. In addition, a state vector is added to the transport address information side of the Response-message. In this example the vector comprises two timestamp based state elements for full servers PE1 and PE2.

The response message is transmitted to the requested transmitter, i.e., the client module 16 of the full user (PU) (step S3 in Fig. 3). After receiving the response-message, module 16 extracts the transport addresses and state vector from the response-message and writes the data to memory 20. The module also passes control to the server selection module 18.

In order to select a particular server to receive the service request (perform step S5 of FIG. 3), the selection module 18 first loads two state vectors into the working memory, the first state vector being the server usability module 22. And the second state vector is the state vector received from the name server as mentioned above.

Server usability module 22 determines status information regarding the usefulness of one or more pull element (s) and accesses memory 20 to write status information to memory 20. In particular, module 22 determines a positive timestamp value each time, and the timers for message transactions at the transport and application layers do not expire, i.e. each transaction receives an acknowledgment, response or other response from the full server. Successfully completed If the timer for the transfer to the server or the application connection expires (i.e. no in-time reply is received), then the current negative timestamp value at timer expiration is determined locally by the availability module 22. 1 is recorded in the state vector.

As mentioned above, the selection module 18 loads two state vectors. Next, module 18 determines the updated local state vector by replacing each entry in the local state value with the corresponding value of the name server state vector, in which case the absolute values of the corresponding value (ie '-'). Symbol is ignored), which means that the status measurement by the name server is more recent than the status measurement performed locally by the usability module 22, ie more recently.

By way of example, the stored local (first) state vector may indicate the state of PE1, i.e., <-A668, A794> at 11:50 (unreachable) and 11:55 (reachable), such as The local vector is then updated at two locations to yield <A8C0, -A8C1>.

The updated vector is written to memory at the location of the local vector. The storage location of the vector received from the name server NS may be used for different purposes inside the mobile device.

In further steps (step 5 of FIG. 3), server selection module 18 determines the server to be selected by evaluating the highest value in the updated state vector. In the above example, the highest value is 'A8C0' stored at the position indicating the pull element PE1. Thus, module 18 creates a pointer to point to a storage location within memory 20 that contains other data, such as the transport address and port address for PE1, and returns the pointer to the calling application to service from PE1. To request.

The specific examples described herein depict only one suitable embodiment according to the present invention. Many other embodiments are possible using the known art, within the scope of the invention, which is specified only by the appended claims.

For example, the devices and modules described herein may be implemented as hardware or firmware. However, preferably, they are implemented in software. For example, a full user device that includes the modules or any other modules as described above may be implemented on a mobile device as an applet.

Reference Symbols List

NS name server

PE1, PE2 full elements

PU full user

SP server pool

10 Pool Analysis Server Module

12 element status module

14 Name Server (NS) Memory

16 Pool Analysis Client Module

18 Server Selection Module

20 full user (PU) memory

22 Server Usability Module

S1-S5 Method Steps

Claims (19)

A method of providing reliable server functionality in supporting a service or set of services, such as Internet-based applications, Forming a server pool (SP) having one or more pool elements (PE1, PE2), each of the pool elements (PE1, PE2) may support the service or set of services; Providing at least one name server (NS) for managing and maintaining a namespace for said server pool (SP), said namespace comprising a full name identifying said server pool (SP); Sending a request to the name server (NS) informing the full name by a full user (PU) for using the service or set of services; Analyzing, by the name server, the full name against a Name Resolution List that includes address information, such as an IP address for one or more of the pool elements (PE1, PE2); Transmitting, by the name server (NS), a Name Resolution List to the full user (PU); And The pool user (PU) accessing one of the pool elements (PE1, PE2) of the server pool (SP) to use the service or set of services based on the address information from the Name Resolution List , As a way to provide reliable server functionality, Transmits state information regarding an operational state of one or more pool elements PE1 and PE2 from the name server NS to the pool user PU, The full user PU determines a state vector including state information regarding the usefulness of the one or more pool elements PE1 and PE2, and the state vector determined by the full user PU is determined by the name server. Is updated by the state vector received from NS), The status information regarding the usability may include one or more timers for message transmission between the full user (PU) and the one or more pool elements (PE1, PE2) at the application layer and the transport layer, or at the application layer or at the transport layer. Determined by their expiration or non-expiration, How to provide reliable server functionality. The method of claim 1, The state information indicates a timestamp indicating when the state of one of the pull elements PE1 and PE2 is determined. How to provide reliable server functionality. The method of claim 2, The state of one of the pull elements PE1, PE2 is in response to a Keep-Alive-message sent by the name server NS to one of the pull elements PE1, PE2. Based on a Keep-Alive-Acknowledgement-message received by the name server NS from one pool element of the pull elements PE1, PE2 or a pool of one of the pull elements PE1, PE2. Based on a local timer expiration notification at the name server (NS) due to the disappearance of a Keep-Alive-Acknowledgement-message from an element, The Keep-Alive-Acknowledgement-message and the local timer expiration notification indicate the state of one pull element of the pull elements PE1, PE2, respectively, such as an up and down state, How to provide reliable server functionality. The method of claim 2 or 3, When the one pull element among the pull elements PE1 and PE2 is in an up-state, the state information includes a positive number indicating the timestamp, When the one pull element of the pull elements (PE1, PE2) is in the down-state, comprising a negative number representing the timestamp with a minus sign, How to provide reliable server functionality. The method according to any one of claims 1 to 3, The transmission of the request to the name server NS by the full user PU is performed by sending a name resolution message, wherein the transmission is performed to complete the cache population. Triggered within, How to provide reliable server functionality. The method according to any one of claims 1 to 3, The transmission of the name resolution list by the name server NS to the full user PU includes the transmission of a name resolution response message further comprising the status information, whereby the status information is the status vector as the state vector. Inserted into the Response message, How to provide reliable server functionality. The method according to any one of claims 1 to 3, One of the pool elements PE1 and PE2 in the server pool SP is selected for the server function based on state information of the state vector received from the name server NS, How to provide reliable server functionality. The method of claim 1, The state vector determined by the full user PU is updated by replacing state information with corresponding state information of the state vector received from the name server NS, in which case the corresponding state information is more Indicated as being the absolute value of the latest higher timestamp, How to provide reliable server functionality. The method of claim 5, wherein In selecting a particular one of the pool elements PE1 and PE2 in the server pool, a different server selection policy is used by the pool user PU, the server selection policy being the Maximum Availability SSP or its extension. Including one of the How to provide reliable server functionality. Name to manage and maintain a namespace for a server pool (SP) with one or more pool elements (PE1, PE2) to provide reliable server functionality in supporting a service or set of services, such as Internet-based applications. In the server NS, A pool analysis server module 10 for receiving a request indicating a full name, such as a name Resolution message according to the IETF ASAP protocol, and A memory 14 for storing address information such as an IP address for the pool elements PE1, PE2 associated with a pool name identifying the server pool SP-the pool analysis server module 10 In response to the request, by accessing the memory 14 and extracting address information associated with the full name, the full name for the name resolution list is analyzed and the Name as a Name_Resolution_Response-message according to the IETF ASAP protocol. A name server (NS) comprising an assembled message containing a Resolution List and adapted to send the message to the requesting transmitter, The memory 14 is further adapted to store state information associated with one or more pull elements PE1, PE2, The pool analysis server module 10 accesses the memory 14 to extract the state information in response to the request, inserts it into the message as a state vector and sends the state information to the requested transmitter 16. Which is more adapted to transmit Name server. The method of claim 10, Assemble a Keep-Alive-message, such as Endpoint_Keep_Alive-message, according to the IETF ASAP protocol, send the Keep-Alive-message to one full element of the pull elements PE1 and PE2, and keep-Alive-Acknowledgement Receive a message or receive a local timer expiration notification or local timer expiration, such as an Endpoint_Keep_Alive-Ack-message according to the IETF ASAP protocol, from one of the pull elements PE1, PE2, and respond to the receipt Accessing the memory 14 to write each state information indicating the state of one of the pull elements PE1, PE2, such as up and down states, Comprising an element status module 12, Name server. The method of claim 11, The element status module 12 is adapted to record a number representing a timestamp as the status information, Name server. Full user device (PU) for using server functionality in supporting a service or set of services, such as Internet based applications, which may be provided by each of one or more pool elements (PE1, PE2) of the server pool (SP) To Assemble a request indicating a full name identifying the server pool (SP), such as a Name_Resolution-message according to the IETF ASAP protocol, send the request to a name server (NS), and Name_Resolution_Response- according to the IETF ASAP protocol A pool analysis client module 16 for receiving from the name server NS a message comprising a name resolution list such as a message; And A server selection module for accessing a particular one of the pool elements PE1, PE2 of the server pool SP based on address information from the name resolution list for use of the service or set of services; Which contains 18), As a full user device, The pool analysis client module 16 is further adapted to receive the message comprising a state vector, The server selection module 18 is further adapted to access the particular one pull element of the pull elements PE1, PE2 in response to state information included in the state vector, The analysis client module 16 determines a state vector containing state information regarding the usefulness of the one or more pool elements PE1 and PE2 and uses the state user vector as the state vector received from the name server NS. Is further adapted to update the state vector determined by PU), and The pool analysis client module 16 may be configured to transmit one or more messages related to message transfer between the pool user PU and the one or more pool elements PE1 and PE2 at the application layer and the transport layer, or at the application layer or the transport layer. Adapted to determine the state information regarding the availability by expiration or non-expiration of timers, Full user device. The method of claim 13, Memory 20 for storing state information, such as a state vector, wherein the pool analysis client module 16 and the server selection module 18 are each adapted to record and read the state information, Full user device. The method of claim 14, A server usability module 22 for determining status information regarding the usefulness of the one or more pull elements PE1, PE2 and for accessing the memory 20 to write the status information, Full user device. The method of claim 15, The server selection module 18 is adapted to update the state vector recorded in the memory 20 by the server usability module 22 by the state vector received by the pool analysis client module 16, Full user device. The method according to any one of claims 13 to 16, In selecting a particular one of the pool elements PE1 and PE2 of the server pool SP, another server selection policy is used by the server selection module 18, the server selection policy being Maximum Availability. Comprising an SSP or one of its extensions, Full user device. delete delete

Images