RU2329609C2 - Method of ensuring reliable server function in support of service or set of services - Google Patents

Abstract

FIELD: information technology.

SUBSTANCE: function is provided by the server farm with one or more farm elements; each of the elements can support a service(s) where the performance, reliability and readiness of the server function are enhanced comparing to the existing methods, by the means of sending the operation status information of at least one of the farm elements, from the name server to the farm user.

EFFECT: enhancing reliability and functionality of the server.

17 cl, 4 dwg

Description

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

R. Stewart et al.: “Aggregate Server Access Protocol” Internet Draft, [Online] June 9, 2004 (2004-06-09), pages 1-43, XP002308317 IETF, obtained from the Internet: URL: http: // www.watersprings.org/pub/id/draft-ietf-rserpool-asap-09.txt> [found 11/30/2004], describes that a generic server access protocol (ASAP) along with an endpoint name resolution protocol (ENRP) provides a very useful mechanism for transmitting data over IP networks. ASAP uses a name-based addressing model that isolates the logical endpoint from its IP address (s), thus effectively eliminating the binding between the endpoint and its physical IP address (s), which usually constitutes the only vulnerable link.

Q. Xie et al.: “Rserpool Redundancy-model Policy” Internet Draft, [Online] June 9, 2004 (2004-06-09), pages 1-43, XP002308317 IETF, obtained from the Internet: URL: http: / /www.watersprings.org/pub/id/draft-ietf-rserpool-asap-09.txt> [found 11/30/2004], defines the Rserpool Redundancy model participant selection strategy parameter and related procedures. This strategy is designed to be flexible and capable of supporting the wide range of advanced redundancy models found in some high availability systems. The project takes advantage of the build-up capability of the Rserpool survey load balancing strategy.

US 2003/0101258 A1 discloses a method for monitoring replica servers in a network computing system in which each server in the system has a replica partner vector table that includes status information about other servers in the system. The replica partner vector table includes data fields for storing the update sequence number and timestamp information that identifies the time of the last update and / or time of the last successful replication attempt for each replica server in the system. After each successful replication, the server updates the data items in the replica partner vector to reflect the updated USN and timestamp information. The replica monitoring method evaluates USN and timestamp elements in the replica partner's vector table to determine if any servers in the system are hidden. If the monitoring method detects that the server in the system is hidden, a warning is generated by which users and / or the network administrator are notified of the problem.

In order to increase availability and reliability with respect to access services provided through server-based functions, such as Internet-based applications, it is becoming more and more popular to provide a server pool instead of just one server. Each of the servers in the server pool, called a pool element, is capable of supporting the requested service or set of services.

In order to maintain high performance, availability and scalability of applications, it is required to maintain tracking of those servers that are in the pool and are able to accept requests, and the path for the client in order to contact the desired server. These topics are discussed in an IETF (Internet Engineering Task Force) working group document, “Reliable Server Pooling,” called the RSerPool working group. The architecture of reliable server pooling is standardized within the framework of this working group, see, for example, the definition of a failover platform for reliable server pooling described in Tuexen et al., "Architecture for Reliable Server Pooling", <draft-ietf-rserpool-arch -07.txt>, October 12, 2003.

RserPool defines three types of architectural elements:

pool elements (PEs): servers that provide the same service within the pool;

pool users (PU): clients served by PE;

name servers (NS): servers that provide the translation service to the PU and monitoring the state of PE elements.

In RserPool, pool elements are grouped into a pool. The pool is identified by a unique pool name. To access the pool, the pool user accesses the name server for information.

Figure 1 schematically depicts the well-known architecture of RSerPool. Before sending data to the pool (defined by the pool name), the pool user submits a name resolution request to the name server (or ENRP, see below). The ENRP server resolves the pool name to the transport addresses of PE elements. Using this information, the PU can select the PE transport address in order to send data to it.

RSerPool contains two protocols, namely the generalized server access protocol (ASAP) and the endpoint name resolution protocol (ENRP). ASAP uses a name-based addressing model that isolates the logical endpoint from its IP address (s). Name servers use ENRP to communicate with each other in order to exchange information and updates regarding server pools. An ASAP instance (or ENRP) running on this entity is referred to as an ASAP endpoint (or ENRP) of that entity. For example, an ASAP instance running in a PU is called the ASAP endpoint of the PU user.

Each time a PU sends a message to a pool that contains more than one PE, the ASAP endpoint of the PU user must select one of the PEs in the pool as the receiver of the current message. The selection is made in the PU according to the current server selection strategy (SSP). Four main SSP strategies are currently under discussion in order to be used with ASAP, namely the round-robin service algorithm ("carousel"), the least used, the least used with degradation and the weighted round-robin algorithm, see R.R. Stewart, Q. Xie: Aggregate Server Access Protocol (ASAP), <draft-ietf-rserpool-asap-08.txt>, October 21, 2003.

The simplified sequence example diagram of FIG. 2 schematically illustrates a sequence of events when a PU user ASAP endpoint populates the cache [Stewart & Xie] for a given pool name and selects PE according to the state of the art.

Filling (updating) the cache means updating the local name cache with the latest name-address matching data found by the ENRP server.

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

S1: The ASAP endpoint of the PU user sends a NAME RESOLUTION request (name resolution) to the ENRP server requesting all the information about the given pool name.

S2: The ENRP server accepts the request and finds the database item for a specific pool name. The ENRP server retrieves transport address information from a database item.

S3: The ENRP server creates a NAME RESOLUTION RESPONSE (name resolution response) into which the transport addresses of the PE elements are inserted. The ENRP server sends NAME RESOLUTION RESPONSE to the PU user.

S4: The PU user ASAP endpoint fills (updates) its local name cache with the transport address information of the pool name.

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

In the end, the PU gains access to the selected server to use the service / services.

Existing static server selection strategies use predefined schemes to select servers. Examples of static SSPs are:

- "carousel" is a cyclic strategy where servers are selected in a sequential manner until the initially selected server is selected again;

- A weighted carousel is a simple extension of the carousel. She assigns a certain weight to each server. Weight indicates server processing performance.

Lack of awareness of the dynamic conditions of the system leads to low complexity, however, if there are costs from declining performance and reliability of service, adaptive (dynamic) SSPs make decisions based on changes in the state of the system and dynamic assessment of the best server. Examples of dynamic SSPs are

- least used server strategy (SSP): In this SSP, the load on each server is observed by the client (PU). Based on monitoring server loads, each server is assigned a so-called strategy value, which is proportional to the server load. According to the least used server strategy, the server with the lowest strategy value is selected as the receiver of the current message. It is important to note that this SSP implies that the same server is always selected as long as the server strategy values are updated and changed.

- The strategy of the least used server with degradation is the same as the strategy of the least used server, with one exception. Namely, every time the server with the lowest strategy value is selected from the set of servers, its strategy value increases. Thus, this server may no longer have the least strategy value in the server set. Over time, this leads to the strategy of the least used server with degradation to a carousel SSP. Each update to the server strategy values returns the SSP back to the least-used degraded server strategy.

The performance of a dynamic SSP is heavily dependent on the metric used to rate the best server. Research at SSP has mainly focused on replicated web server systems. In such systems, typical metrics are based on server proximity, including geographic distance, the number of relayings to each server, full round-trip time (RTT), and HTTP response times. Although SSPs on web systems are designed to provide high throughput and low latency, for example, session control protocols such as SIP deal with messages that are fairly small (500 bytes on average). Thus, throughput is not as significant as in web systems. As far as the authors know, SSPs have not been widely studied, for example, with session management systems.

In light of the aforementioned prior art, an object of the present invention is to provide a method of providing a server function in supporting a service or a set of services, such as Internet-based applications, a server function is provided by a server pool with one or more pool elements, each of the pool elements is capable of supporting the service / services, where the reliability and availability of the server function is improved relative to existing methods, and also to offer a name server and a pool user device that implements such a method.

This problem is solved by a method with a combination of features, as described in clause 1, and through a name server and a pool user device, as indicated in clause 12 or 15, respectively.

One of the fundamental ideas underlying the present invention is to organize the use of messaging between the pool user and the name server to provide the pool user with (additional) status information related to the elements of the pool from the name server. Since the name server is the node assigned to the server pool, in general it will have better information regarding the state of the elements of the pool, for example, their current state, based on the latest availability messages.

At the very least, the name server has additional status information in its location, which, if provided to the pool user, generally offers the opportunity to make selection decisions, resulting in improved performance, reliability and high availability of server functions that must be performed by server pool elements. Through this, response times as well as server pool load situations can be optimized.

Moreover, it is possible to easily provide the pool user server selection module with status information from the name server, as in any case, the pool user needs to exchange messages in order to find the transport addresses of the pool elements.

The invention described herein thus essentially provides an extension of the RSerPool protocol, where a corresponding extension of the RSerPool architecture can easily be implemented on the name server and user of the pool.

According to the invention, failure detection mechanisms are distributed in a pool user and a name server. The pool user uses application and transport layer timers to detect data transmission failure, while name servers provide an availability mechanism to periodically monitor PE status.

The invention will now be described with respect to a separate server selection strategy called Maximum Availability SSP (MA-SSP), which is an occasion to separate the applicant's application. The invention, however, is not limited to this MA-SSP, but may be based on any static or dynamic SSP that is known or should be developed in the future.

MA-SSP works with the so-called state vector. According to MA-SSP, the state vector has size N (i.e., it is equal to the number of pool elements in this server pool) and is defined as follows:

p = [p ₁ , p ₂ , • • •, p _N ]

A specific element in the state vector represents the last known state moment of an individual PE. If the last PE state was ON, the time value is kept unchanged in the state vector. If the last PE state was OFF, the time value is stored in the status vector with a negative sign. The MA algorithm always selects the PE that has the maximum value in the state vector.

The PU user ASAP endpoint updates its state vector. In the future, the state vector PU is denoted as p ^(u) . According to the original RSerPool specification [Tuexen et al .; Stewart & Xie] the name server returns the transport addresses of the pool servers. In order to smoothly integrate, for example, MA-SSP into the RSerPool architecture, the RSerPool extension is defined. This RSerPool extension, which can be used for other SSPs to some degree in the same way, is described in the following text.

The extension in RSerPool affects the communication between the PU and NS, namely the ASAP endpoints of the NS server and the PU user. This document is taken for illustrative purposes that both the PU and the ENRP server use the MA algorithm. The MA algorithm in the ENRP server creates a state vector for each server pool. This state vector is updated periodically by using the existing ASAP accessibility mechanism [Stewart & Xie]. The authors will further designate the state server of the name server as p ^(s) . The vector p ^(s) for this pool is stored in the aforementioned database item in the name server reserved for this pool. Authors will assume that there are N pool elements in the pool.

The PU initiates cache filling in the following two cases:

1) The PU wants to fill (update) the cache in order to update its vector p ^{(u) with the} latest information from the name server.

2) The PU wants to resolve the pool name.

In either case, the ASAP endpoint of the PU user sends a NAME RESOLUTION request to the ENRP server through ASAP. The ENRP server accepts the request and finds a database item for a specific pool name. The database item contains the latest version of the vector p ^(s) . The ENRP server performs the following actions:

1) The ENRP server retrieves transport address information from the database item.

2) The ENRP server extracts the vector p ^(s) from the database element.

3) The ENRP server creates a NAME RESOLUTION RESPONSE into which the transport addresses of the PE elements are inserted. In addition to the transport address information, the name response is expanded with an additional field. The vector p ^{(s) is} inserted in this additional field.

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

Thus, NAME RESOLUTION RESPONSE contains the most recent version of the vector p ^{(s) of} the ENRP server. After the PU receives NAME RESOLUTION RESPONSE, it updates the local name cache (transport address information) in the same way as its p ^(u) vector. The procedure for updating the p ^(u) ASAP PU vector is as follows:

(1)

(one)

where p _i ^(u) and p _i ^(s) are the ith elements of p ^(u) and p ^(s) , respectively.

It should be noted that this works well in the context of synchronized timers for pool users and name servers. This becomes a problem if the intertemporal deviations are unacceptably large. Using a time synchronization protocol such as Network Time Protocol (NTP) resolves this issue.

Advantageously, the extension of the RSerPool protocol required for carrying out the invention is quite simple and easily entered into RSerPool. Moreover, the protocol extension is transparent to the application layer in the PU, i.e. the client. The state vector is processed at the ASAP level of the PU protocol stack. Thus, the protocol extension is transparent to the application layer above the ASAP layer. Each PU supporting this protocol extension benefits from the performance improvements provided by the invention.

Further aspects and advantages of the invention can be obtained from the attached claims in the same way as from the following description of an embodiment of the invention with reference to the accompanying drawings, showing

figure 1 (discussed above) as a simplified block diagram of the General architecture of RSerPool according to the prior art;

figure 2 (discussed above) is a simplified sequence diagram illustrating the exchange of messages between the pool user and the name server of figure 1 according to the prior art;

FIG. 3 is a sequence diagram as in FIG. 2, illustrating the exchange of messages between a name server and a pool user according to an embodiment of the claimed method;

FIG. 4 is a block diagram showing the essential functional blocks of a name server and a pool user device, relevant to the embodiment of the invention illustrated in FIG. 3.

A schematic drawing summarizing the basic principle of the invention is shown in FIG. Steps S1-S4 for populating the cache, as defined in this invention, are explained as follows:

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

2) Receiving a request and retrieving a database item for a specific pool name through the NS name server. The name server NS retrieves transport address information from the database element in the same way as the vector p ^(s) .

3) Creating a NAME RESOLUTION RESPONSE, which includes the transport addresses of PE and the vector p ^(s) , using the NS name server. The NS name server sends NAME RESOLUTION RESPONSE to the PU of the pool.

4) Filling (updating) the local name cache by means of the ASAP endpoint of the user of the PU pool with information about transport addresses by the pool name. The pool user ASAP endpoint applies the simple procedure described in equation (1) above to update the state vector p ^(u) .

5) Selecting an individual element of the pool or server to send him a service request.

The implementation of the invented method can be performed quite simply. NAME RESOLUTION RESPONSE is extended with a separate field that contains the state vector p ^(s) . Figure 4 shows the principal functional components of a PU pool user and a name server NS, the latter being illustrated associated with a server pool SP with two pool PE elements.

The name server NS includes a pool resolution server module 10, an element state module 12, and a memory 14. The element state module 12 periodically composes the endpoint availability messages according to the IETF ASAP protocol [Stewart & Xie] and sends these messages to each of the servers PE1, PE2.

Assuming that server PE1 is in an “on” state (server PE1 is ready to provide server function upon request, for example, a PU client), server PE1 responds to the availability message from the NS server by sending an endpoint availability confirmation message back to the NS name server.

Assuming further that the PE2 server is in the “off” state (the PE2 server is not ready for maintenance), the PE2 server does not respond to the availability message from the NS name server, whereby the local timer initiated for this support message on the NS server, expires according to the IETF ASAP protocol.

The element state module 12 holds a state vector that is stored in the memory 14. The vector contains for each element PE1, PE2 of the pool SP a number representing a time stamp that indicates the processing time of each element's response to the support message. The availability confirmation message received from PE1 thus causes the module 12 to write the time stamp 'A8C0' (hex) to the position of the status vector provided for the server PE1, assuming that the acknowledgment message was processed at twelve o'clock, as measured by a synchronization unit (not shown ) in the name server, and the timestamp is accurate in units of seconds. An unavailability message received from PE1 causes module 12 to write the timestamp '-A8C1' (hex) to the position of the status vector provided for the PE2 server, assuming that the unavailability message was processed within one second after twelve hours.

The functionality of the server module 10 is described in more detail below with respect to a request from a PU pool user. The PU of the pool comprises a pool resolution client module 16, a server selection module 18, a memory 20, and a server ready module 22.

The user of the PU pool is implemented in a mobile device (not shown) capable of transmitting data and voice over a UMTS network, the pool of SP servers and the NS name server are its parts. The device application wants to access the service provided by any of the SP pool servers. In this example, the pool of SP servers is a "farm" or a set of servers that implements services related to the IMS (IP multimedia subsystem) domain of the UMTS network. The application is an example of a SIP-based application.

To request a separate service, an application running on a mobile device (not shown) only knows the pool name. The application launches part of the pool user (containing the ASAP endpoint) of the mobile device by passing the pool name. The pool resolution client module composes the name resolution message according to the ASAP protocol and sends it to the name server NS (step S1 in FIG. 3).

A name resolution message is received at the NS server by the server pool resolution module 10. The pool name is retrieved, and the server module 10 accesses the memory 14 to retrieve address information that is stored associated with the pool name. In this example, the IP addresses of the pool elements PE1, PE2 are read from memory 14 together with the port address that should be used to request a separate service, and, according to the invention, also time stamps 'A8C0', '-A8C1' stored in associative communication with servers PE1, PE2, read from memory 14. Step S2 in FIG. 3 ends here.

The server module 10 composes a name resolution response message according to the IETF ASAP protocol, which contains a name resolution list with transport addresses of elements PE1, PE2, as is known in the art. Further, the state vector is attached to the part of the transport address information in the response message. The vector in this example contains two time-based status items for the pool servers PE1, PE2.

A response message is sent to the sender of the request (step S3 in FIG. 3), i.e. client module 16 user PU pool. After receiving the response message, the module 16 extracts the transport addresses and the state vector from the response message and writes data to the memory 20. Next, the module takes control of the server selection module 18.

In order to select a specific server for sending it a service request (i.e., perform step S5 in FIG. 3), the selection module 18 first loads two status vectors into the working memory, the first one that was determined by the server ready module 22, the second is a state vector received from the name server as described above.

The server availability module 22 determines status information related to the availability of one or more elements of the pool and accesses memory 20 to record status information there. In particular, module 22 determines a positive value of the time stamp for each time, the timer for processing the message at the transport and application levels does not expire, i.e. appropriate processing is successfully completed by receiving an acknowledgment, response, or other response from the pool server. In the case where the timer related to the transport or application connection with the server expires (i.e., the response is not received on time), the negative value of the current time stamp at the end of the timer is written to the first state vector determined locally by the ready module 22.

As mentioned above, the selection module 18 loads both state vectors. Module 18 then determines the updated local state vector, replacing each element in the local state value with the corresponding value of the name server state vector in the case when this corresponding value in absolute terms (i.e. ignoring the '-' sign) is the largest, which means that measuring the state of the name server is more recent, i.e. was performed more recently, the state measurement is performed locally by the standby module 22.

As an example, the saved local (first) state vector can represent state PE1 at 11:50 (unavailable) and 11:55 (available), i.e. <-A668, A794>, then the local vector is updated at both positions with the result <A8C0, -A8C1>.

The updated vector is written back to memory at the position of the local vector. The storage position for the vector received from the NS name server can be used for various purposes within the mobile device.

In the next step (step 5 in FIG. 3), the server selection module 18 determines the server to be selected by estimating the highest value in the updated status vector. In this example, the largest value is 'A8C0', stored at the position indicating the PE1 element of the pool. Thus, module 18 creates a pointer indicating a storage position within memory 20 containing the transport address and additional data, such as a port address related to PE1, and returns this pointer back to the calling application to allow it to request service from PE1.

The specific example described here illustrates only one suitable embodiment of the invention. Within the scope of the invention, which is precisely defined by the appended claims, many additional embodiments are available through skilled practice.

For example, devices and modules, such as those described herein, may be implemented as hardware or firmware. Preferably, however, they are implemented as software. For example, a pool user device containing any additional modules, as described above, may be implemented in the mobile device as an applet.

Claims (17)

1. A way to provide reliable server function in service support or a set of services, such as Internet-based applications, the method comprises the following steps, in which form a pool (SP) of servers with one or more elements (PE1, PE2) of the pool, and each of the elements (PE1, PE2) of the pool can support the service (s), provide at least one name server (NS) for managing and maintaining the namespace for the pool (SP) of servers, the namespace containing a pool name identifying the pool (SP) of servers, send by the user (PU) of the pool, to use the service / services, a request to the server (NS) names indicating the name of the pool, resolving, by the name server (NS) upon request, the pool name to the name resolution list, the name resolution list containing address information such as an IP address relating to one or more elements (PE, PE) of the pool, send a name resolution list by the name server (NS) to the pool user (PU), get access, through the user (PU) of the pool and based on the address information from the name resolution list, to one of the elements (PE1, PE2) of the server pool (SP) for using the service / services, characterized in that send status information related to the operational state of at least one of the elements (PE1, PE2) of the pool from the name server (NS) to the pool user (PU), the user (PU) of the pool defines a state vector containing status information related to the availability of one or more of the elements (PE1, PE2) of the pool, and the state vector defined by the user (PU) of the pool is updated by a state vector received from the server (NS ) names, and status information related to availability is determined after the expiration or non-expiration of the time of one or more timers related to the transmission of a message between the pool user (PU) and one or more of the pool elements (PE1, PE2) at the application level and / or transport level. 2. The method according to claim 1, characterized in that the status information is a time stamp indicating the point in time at which the state of one of the elements (PE1, PE2) of the pool is determined. 3. The method according to claim 2, characterized in that the state of said one of the pool elements (PE1, PE2) is determined based on the availability confirmation message received by the name server (NS) from one of the pool elements (PE1, PE2) in response to the availability message sent by the name server (NS) to one of the elements (PE1, PE2) of the pool, or a notification about the expiration of the local timer on the name server (NS) due to the lack of an availability confirmation message from one of the elements (PE1, PE2) of the pool, an availability confirmation message and a local timer expiration notification indicate the status of one of the elements (PE1, PE2) of the pool, for example, such as turning it on and off, respectively. 4. The method according to claim 2 or 3, characterized in that the status information contains a positive number, for example, representing a time stamp, if said one of the elements (PE1, PE2) of the pool is in the “on” state, and status information contains a negative number, for example, representing a time stamp with a minus sign, if one of the pool elements (PE1, PE2) mentioned is in the “off” state. 5. The method according to claim 1, characterized in that the step of sending the request by the user (PU) of the pool to the name server (NS) is performed by sending a name resolution message, the sending being triggered by the user (PU) of the pool to fill the cache . 6. The method according to claim 5, characterized in that the step of sending the name resolution list by the name server (NS) to the pool user (PU) comprises transmitting a name resolution response message that further comprises status information, wherein state is preferably inserted in the name resolution response message as a state vector. 7. The method according to claim 1, characterized in that a particular one of the elements (PE1, PE2) of the pool in the server pool (SP) is selected for the server function based on the status information in the state vector received from the name server (NS). 8. The method according to claim 1, characterized in that the state vector defined by the user (PU) of the pool is updated by replacing the state information with the corresponding state information of the state vector received from the name server (NS), in the case when the corresponding state information is indicated as more recent, for example, when the absolute value of the time stamp is higher. 9. The method according to any one of claims 5 to 8, characterized in that at the stage of selecting a particular one of the elements (PE1, PE2) of the pool in the server pool, by the user (PU) of the pool, a server selection strategy is additionally applied, in particular, SSP with maximum readiness or one of its extensions. 10. A name server (NS) for managing and storing a namespace for a pool (SP) of servers with one or more pool elements (PE1, PE2) to provide reliable server functions while supporting a service or set of services, such as Internet-based applications, moreover, the name server contains a pool resolution server module (10) for receiving a request, preferably a name resolution message, according to the IETF ASAP protocol indicating a pool name, and a memory (14) for storing address information, such as an IP address, related to the pool elements (PE1, PE2) associated with the pool name identifying the server pool (SP), moreover, the server module (10) for resolving the pool is intended for resolving, in response to a request, the name of the pool in the name resolution list by accessing the memory (14) and retrieving the address information associated with its pool name, and for composing a message containing the permission list names, such as a name resolution response message according to the IETF ASAP protocol, and for sending a message to the sender (16) of the request, characterized in that the memory (14) is further provided for storing status information associated with one or more elements (PE1, PE2) of the pool, and the server module (10) for resolving the pool is additionally designed to access, in response to the request, memory (14) for retrieving status information and sending status information back to the sender (16) of the request, preferably by inserting status information into the message in as a state vector. 11. The name server of claim 10, characterized by an element state module (12) for composing an availability message, preferably an endpoint availability message according to the IETF ASAP protocol, and for sending an availability message to one of the pool elements (PE1, PE2) and for receiving an availability confirmation message or receiving a local timer expiration notification, preferably an endpoint availability confirmation message or a local timer expiration message according to the IETF ASAP protocol from one of the cops (PE1, PE2) of the pool and, in response to this trick, to gain access to the memory (14) for recording status information indicating the state of the said one of the elements (PE1, PE2) of the pool, preferably as being on or off , respectively. 12. The name server according to claim 11, characterized in that the element state module (12) is intended to be recorded as state information of a number representing a time stamp. 13. The pool user device (PU) for using the server function to support a service or set of services, for example, Internet-based applications, which can be provided by each of one or more server pool (SP) elements (PE1, PE2), wherein the pool user device contains a pool resolution client module (16) for composing a request, preferably a name resolution message according to the IETF ASAP protocol, indicating a pool name identifying a server pool (SP) for sending a request to a server (NS) of names and receiving a message containing a name resolution list, preferably a response a name resolution message according to the IETF ASAP protocol from the name server (NS), a server selection module (18) for accessing based on address information from a name resolution list to a particular one of the elements (PE1, PE2) of the server pool (SP) for using the service / services, characterized in that the pool resolution client module (16) is additionally designed to receive a message containing a state vector, and the server selection module (18) is further designed to access a particular one of the pool elements (PE1, PE2) in response to the status information included in the vector state, and the client permission module (16) is also designed to determine the state vector containing state information related to the availability of one or more elements (PE1, PE2) of the pool, and update the state vector, determine a user pool (PU) by a state vector received from a name server (NS), and the client resolution module (16) of the pool is designed to determine status information related to availability after one or more timers related to the transmission of a message between the pool user (PU) and one or more pool elements (PE1, PE2) on application level and / or transport level. 14. The pool user device according to item 13, characterized by a memory (20) for storing status information, preferably a state vector, while the client pool resolution module (16) and the server selection module (18) are used to write and read information, respectively about the condition. 15. The pool user device according to claim 14, characterized in a server readiness module (22) for determining status information related to the readiness of one or more pool elements (PE1, PE2) and accessing memory (20) for recording status information . 16. The pool user device according to claim 15, characterized in that the server selection module (18) is designed to update the state vector recorded by the server availability module (22) in the memory (20) by means of the state vector received by the client resolution module (16) the pool. 17. The pool user device according to any one of claims 13-16, characterized in that when selecting a particular one of the pool elements (PE1, PE2) in the server pool (SP) through the server selection module (18), a server selection strategy is additionally applied, in in particular, SSP with maximum availability or one of its extensions.

Images