Subject: [Rserpool] Services Provided By Reliable Server Pooling

From: [email-masked]
Date: Tue, 21 May 2002 13:44:37 -0500

Phil and Peter,

Here are my initial comments on draft-conrad-rserpool-service-00.txt section 3.2.

3.2 Example Scenario for RSerPool Nameservice Mode

I'm confused about the implementation of ASAP 03 and ENRP 03 for
applications using name service mode.

1) The document does not state if ASAP 03 as defined for the client needs to
be fully implemented or not.

----------------------- start of text -----------------------------------------------------------------------

2. Instead of using a DNS based service (e.g. the Unix library function gethostbyname()) to translate from a hostname to an IP address, the application will invoke an RSerPool service primitive "IPAddressOfPrimaryServer" that takes as input a pool handle, and returns the IP address of the primary server. The application then uses that IP address just as it would have used the IP address returned by the DNS in the previous scenario.

3. In nameservice mode, failure detection is application specific just as in the previous scenario. However, when failure is
detected on the primary server, instead of invoking DNS translation again on the hostname of a secondary server, the application invokes the service primitive "IPAddressOfNextServer", which has a dual meaning. First it indicates to the RSerPool layer the failure of the server returned by a previous "IPAddressOfPrimaryServer" or "IPAddressOfNextServer" call. Second, it provides the IP address of the next server that should be contacted, according to the best information available to the RSerPool layer at the present time.

----------------------------- end of text -------------------------------------------------------

We make it explicit that when messages are sent by the PU and received by
the PE, we don't use the ASAP layer. Specifically, there is no using ASAP
data.send.request and the data.response by the PU. The application does its
communication with the PE as already defined in its legacy application.
Again, this minimizes changes to the app. However, I'm assuming that pool
address caching still goes on in the PU as defined by ASAP. (Am I right
about all this? This is the kind of thing I want to know.)

2) Same comment for the PE. The document does not state if ASAP 03 as
defined for the PE (server) needs to be fully implemented or not. I was
especially confused by the 1. and 2. bullets saying effectively "just add this" to the server.

-------------------------------------- start of text -------------------------------------------------------

For pool element ("server") applications, two additions are required:

1. The server should invoke the REGISTER service primitive upon startup to add itself into the server pool using an appropriate pool handle. This also includes the address(es) protocol or mapping id, port (if required by the mapping), and pooling policy(s).

2. The server should invoke the DEREGISTER service primitive to remove itself from the server pool when shutting down.

------------------------------- end of text -----------------------------------------------------------------

Does this mean that you don't have to implement the full ASAP for the
server, but some subset that is vaguely defined here? For example, does the
server need to respond to an endpoint keep alive message?

Anyway, if this name service mode specifies some subset of ENRP 03 and ASAP
03 for name service mode, then that should be stated directly. Then the
subset should be specified in another document in a detailed manner. If all
of ENRP 03 and ASAP 03 are required to be implemented, then it should
clearly say this -- (the Right Thing in my opinion).

The goal is stated clearly -- that you want to minimize the changes to the
application in this mode and this is a highly desirable goal.

My opinion is that ASAP 03 and ENRP 03 should be fully implemented as
defined even if the application(s) only use name service mode. All we are
doing with name service mode is not taking advantage of the full underlying
power of ASAP and ENRP. The services exposed at the application layer is
different in each mode, thereby making it a smaller task to modify the
application for name service mode. The full power of ASAP and ENRP are there
if you want to tap into them later.

Does this make sense? Comments?

-- maureen

_______________________________________________
rserpool mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/rserpool