GENWiki

Premier IT Outsourcing and Support Services within the UK

User Tools

Site Tools


rfc:rfc1914

Network Working Group P. Faltstrom Request for Comments: 1914 Bunyip Information Systems, Inc. Category: Standards Track R. Schoultz

                                                                KTHNOC
                                                             C. Weider
                                      Bunyip Information Systems, Inc.
                                                         February 1996
                How to Interact with a Whois++ Mesh

Status of this Memo

 This document specifies an Internet standards track protocol for the
 Internet community, and requests discussion and suggestions for
 improvements.  Please refer to the current edition of the "Internet
 Official Protocol Standards" (STD 1) for the standardization state
 and status of this protocol.  Distribution of this memo is unlimited.

1. Overview

 In the Whois++ architecture [Deutsch94],[Weider94], mesh traversal is
 done by the client, since each server 'refers' the client to the next
 appropriate server(s). The protocol is simple. The client opens a
 connection to a  server, sends a query, receives a reply, closes the
 connection, and after parsing the  response the client decides which
 server to contact next, if necessary.
 So, the client needs to have an algorithm to follow when it interacts
 with the Whois++ mesh so that referral loops can be detected, cost is
 minimised, and appropriate servers are rapidly and effectively
 contacted.

Faltstrom, et al Standards Track [Page 1] RFC 1914 How to Interact with a Whois++ Mesh February 1996

2. Basic functionality

 Each Whois++ client should be configured to automatically send
 queries to a specific Whois++ server. The deault Whois++ server can
 vary depending on which template is desired, and the location of the
 client with respect to the WHOIS++ index mesh,  but as a rule the
 server should be as local as possible.
                      A
                     / \
                    B   C
                   / \   \
         Z -----> D   E   F
                 / \
                G   H
     Fig 1: The client Z is configured to first query server D
 After getting responses from a server, the client can act in several
 ways. If the number of hits is greater than zero, the response is
 just presented to the user. If the client gets one or many servers-
 to-ask answers, the client should be able to automatically resolve
 these pointers, i.e. query these servers in turn.
                      A
                     / \
                    B   C
                   / \   \
         Z <----- D   E   F
           \     / \
            --> G   H
 Fig 2: The client Z gets a "servers-to-ask G" response from D and
           therefore may automatically queries server G.

3. How to navigate in the mesh

 A client can use several different strategies when traversing or
 navigating around in the mesh. The automatic way of doing this is to
 just "expand the search" (described in 3.1) and a second method is to
 use the "Directory of Servers" (described in 3.2).

3.1. Expansion of searches

 If the number of hits is zero, or if the user in some way wants to
 expand the search, it is recommended for the client to issue a
 'polled-by' and 'polled-for' query to the server. The client can then
 repeat the original query to the new servers indicated.

Faltstrom, et al Standards Track [Page 2] RFC 1914 How to Interact with a Whois++ Mesh February 1996

                      A
                     / \
            /-----> B   C
           /       / \   \
         Z <----- D   E   F
                 / \
                G   H

Fig 3: The client Z gets a "polled-by B" response from D and therefore

                         queries server B.
 The client must always keep track of which servers it has queried
 because it must itself detect loops in the mesh by not querying the
 same server more than once.
                      A
                     / \
                 /- B   C
                /  / \   \
         Z <---/  D   E   F
                 / \
                G   H
Fig 4: The client Z gets a "servers-to-ask D" response from B but Z
  does not query D because the server D has already been queried.
 So, the default expansion of a query by a client causes increasingly
 more comprenhensive index servers to be queried; the forward
 knowledge contained in the index server mesh allows rapid pruning of
 these larger trees.
 All loop detection and elimination is done in the client, rather than
 in the server mesh. This decision was made because loop detection and
 elimination are quite difficult to build into the mesh if we are to
 continue to allow each server to participate in multiple hierarchies
 within the mesh.

3.1.1. Optimising the mesh

 If organization A tends to use organization B's WHOIS++ server
 frequently, for example if A is cooperating in a project with B, A
 may wish to make B's server locally available by creating a local
 index server which retrieves the centroid for both organizations.
 When A's client then expands a query which is looking for someone at
 B, the client can much more rapidly resolve the query, as it does not
 have to find the top level servers for the tree to which A and B both
 belong.

Faltstrom, et al Standards Track [Page 3] RFC 1914 How to Interact with a Whois++ Mesh February 1996

                      A
                     / \
                    B   C
                   / \   \
         Z        D   --> F
                 / \
                G   H
         Fig 5: The server B gets a centroid from server F
                      A
                     / \
                    B   C
                   / \   \
         Z <----> D   --- F
                 / \
                G   H
Fig 6: The client queries server D, gets zero hits back, expands the
           search and gets a "polled-by B" response back.
                      A
                     / \
               /--> B   C
              /    / \   \
         Z <-/    D   --- F
                 / \
                G   H
  Fig 7: The client Z queries server B and gets "servers-to-ask F"
                           response back.
                      A
                     / \
                    B   C
                   / \   \
                  D   --- F <-----> Z
                 / \
                G   H
     Fig 8: The client Z queries server F and gets the answer.
 The example given in Fig 5-8 shows that the algorithm works even
 though the Whois++ mesh is not a tree. There are many reasons why a
 given index server mesh might be 'short-circuited'. For example, in
 the case of a multinational company, the Swedish branch of Acme Inc.,
 is polled both by the national server in Sweden and the headquarters
 server in the USA. By querying the Swedish server, one finds all

Faltstrom, et al Standards Track [Page 4] RFC 1914 How to Interact with a Whois++ Mesh February 1996

 persons working at the Swedish branch of Acme Inc., but by querying
 the Acme Inc.  server in the USA, you will find all employees in the
 company, including those in Sweden.
 Note that the location of a server does not implicitly narrow the
 search, i.e. you have to specify all information when sending a query
 to a server. In the example above, one can see that by just querying
 a server for companies in the USA, you will not implicitly only get
 hits from records in the states, because the Acme Inc. server in the
 states has polled a server in Sweden. So, in this case you have to
 explicitly include "country=USA" in the query if you are only
 interested in those records.
 Although the WHOIS++ index service has been designed to make searches
 at any location in the index mesh quite effective and efficient,
 blindly expanding the query can incur an exponentially growing cost
 in resources, and, as charging for responses is implemented in parts
 of the WHOIS++ index service mesh, growing cost, automatic expansion
 is not recommended. More sophisticated clients  should also be
 configurable to "cut off" some servers from a search, i.e. a
 blacklist of servers. This might be needed when searching for records
 and one server might have a very high cost (in dollars) so one might
 want to explicitly forbid the client to send queries to that server.

3.1.2. The algorithm used by the client

 By following this algorithm a client finds all records in a mesh
 which the first Whois++ server queried belongs to.
 The algorithm for the client follows:
    Query := data to search for;
    QueriedServers := {};
    AnswerList := {};
    OriginalServers := { known servers to this client };
    while OriginalServers is not empty do:
          ServerList = OriginalServers;
          while ServerList is not empty do:
                Server := ServerList[1];
                if Server is not in QueriedServers then do:
                      send Query to Server;
                      Answer := answer from Server;
                      append ServersToAsk to ServerList;
                      remove Server from ServerList;
                      append Answers to AnswerList;
                end;
          done;
          if query should be expanded then do:

Faltstrom, et al Standards Track [Page 5] RFC 1914 How to Interact with a Whois++ Mesh February 1996

                ServerList := OriginalServers;
                OriginalServers := {};
                while ServerList is not empty do:
                      Server := ServerList[1];
                      send Polled-For-Query to Server;
                      Answer := answer from Server;
                      append Answer to OriginalServers;
                      remove Server from ServerList;
                end;
          done;
    done;
    display AnswerList to user;

3.2. The Directory of Servers

 A second way of finding the correct server to query is to use a
 separate service we call the Directory of Servers. The Directory of
 Servers is a special Whois++ server which polls every Whois++ server
 for information about common information among the records on that
 perticular server.

3.2.1. How should a client use the Directory of Servers?

 A client that want to very quickly find what servers serves USER
 templates in Sweden, should do it this way:
 1) The hostname and portnumber of the directory of Servers have
    to be preconfigured in the current version of the protocol.
 2) Query the Directory of Servers for serverhandle records for
    country sweden. This gives information of all these servers.
    By presenting this information to the user the user should be
    able to start the search at some closer server.
 Note that we at this moment doesn't think this should be an autmatic
 process in the client. The Directory of Servers should be used for
 giving the user information about what Whois++ servers that exists.
 In the future a technique might have developed that makes it possible
 for a client to do this selection automatically depending on the
 query the user issues.

Faltstrom, et al Standards Track [Page 6] RFC 1914 How to Interact with a Whois++ Mesh February 1996

3.2.2. What does the serverhandle record look like?

 The attributes that must be in all serverhandle records are:
 Server-Handle: The handle for this server.
 Host-Name:     The (current) hostname of this server.
 Host-Port:     The (current) portnumber for this server.
 Part from that information, the record can include other attributes
 like:
 Admin-Name:        Patrik Faltstrom
 Admin-Email:       paf@bunyip.com
 Admin-Phone:       +1-514-875-8611
 Organization-Name: Bunyip Information Systems Inc.
 Description:       USER information
 Menu-Item:         World (Bunyip Information Systems inc)
 City:              Montreal
 State:             Quebec
 Country:           Canada
 :
 :
 (Other attributes that can identify all records on this server, for
 example domainname)
 The information in the Navigation record is intended to be presented
 to a user.

3.2.3. Example

 An example of how an interaction with the Directory of Servers is
 done follows. The characters '<' and '>' displays if it is the client
 ('<') or responding server ('>') which is responsible for the output:
% 220-This is services.bunyip.com running Bunyip-Whois++: DIGGER 1.0.5
% 220 Ready to go!

< template=serverhandle and bunyip

% 200 Search is executing
# FULL SERVERHANDLE BUNYIPCOM01 BUNYIPCOM01
SERVER-HANDLE: BUNYIPCOM01
HOST-NAME: services.bunyip.com
HOST-PORT: 63
ADMIN-NAME: Patrik Faltstrom
ADMIN-EMAIL: paf@bunyip.com
ORGANIZATION-NAME: Bunyip Information Systems Inc.
DESCRIPTION: USER information
DESCRIPTION: Directory of Servers
DESCRIPTION: Toplevel Index server in the world

Faltstrom, et al Standards Track [Page 7] RFC 1914 How to Interact with a Whois++ Mesh February 1996

MENU-ITEM: World (Bunyip Information Systems inc)
CITY: Montreal
COUNTRY: Canada
# END

# FULL SERVERHANDLE BUNYIPCOM01 BUNYIPCOM02
SERVER-HANDLE: BUNYIPCOM02
HOST-NAME: services.bunyip.com
HOST-PORT: 7778
ADMIN-NAME: Patrik Faltstrom
ADMIN-EMAIL: paf@bunyip.com
ORGANIZATION-NAME: Bunyip Information Systems Inc.
DESCRIPTION: USER information
MENU-ITEM: Bunyip Information Systems
CITY: Montreal
COUNTRY: Canada
# END

% 226 Transaction complete
% 203 Bye, bye

4. Caching

 A client can cache all information it gets from a server for some
 time.  For example records, IP-addresses of Whois++ servers, the
 Directory of Services server etc.
 A client can itself choose for how long it should cache the
 information.
 The IP-address of the Directory of Services server might not change
 for a day or two, and neither might any other information.

4.1. Caching a Whois++ servers hostname

 An example of cached information that might change is the chached
 hostname, IP-address and portnumber which a client gets back in a
 servers-to-ask response. That information is cached in the server
 since the last poll, which might occurred several weeks ago.
 Therefore, when such a connection fails, the client should fall back
 to use the serverhandle insted, which means that it contacts the
 Directory of Services server and queries for a server with that
 serverhandle.  By doing this, the client should always get the last
 known hostname.

Faltstrom, et al Standards Track [Page 8] RFC 1914 How to Interact with a Whois++ Mesh February 1996

 An algorithm for this might be:
response := servers-to-ask response from server A
IP-address := find ip-address for response.hostname in DNS
connect to ip-address at port response.portnumber
if connection fails {
   connect to Directory of Services server
   query for host with serverhandle response.serverhandle
   response := response from Directory of Services server
   IP-address := find ip-address for response.hostname in DNS
   connect to ip-address at port response.portnumber
   if connection fails {
       exit with error message
   }
 }
 Query this new server

5. Security Considerations

 Security considerations when using the Whois++ protocol is described
 in [Deutsch94].
 A client should be able to have a "blacklist" of servers it should
 not query, because it might happen that fake Whois++ servers is put
 up on the net. When such a fake Whois++ servers is found, a user
 should be able to configure it's client to never query this server.
 Note that a client should be careful when expanding a query by either
 using normal expansion or using the directory of servers. A query
 might take a long time, so a user should be able to quit in the
 middle of such a transaction. This is though more a question of user
 interaction than a plain security issue.

6. References

 [Deutsch94]  Deutsch P., Schoultz R., Faltstrom P., and C. Weider,
              "Architecture of the Whois++ service", RFC 1835,
              August 1995.
 [Weider94]   Weider C., Fullton J., and S. Spero, "Architecture of
              the WHOIS++ Index Service", RFC 1913, February 1996.

Faltstrom, et al Standards Track [Page 9] RFC 1914 How to Interact with a Whois++ Mesh February 1996

7. Authors' Addresses

 Patrik Faltstrom
 BUNYIP INFORMATION SYSTEMS, inc
 310 St Catherine St West, Suite 300
 Montreal, Quebec
 CANADA H2X 2A1
 EMail: paf@bunyip.com
 Rickard Schoultz
 KTHNOC, SUNET/NORDUnet/Ebone Operations Centre
 S-100 44  STOCKHOLM
 SWEDEN
 EMail: schoultz@sunet.se
 Chris Weider
 BUNYIP INFORMATION SYSTEMS, inc
 310 St Catherine St West, Suite 300
 Montreal, Quebec
 CANADA H2X 2A1
 EMail: clw@bunyip.com

Faltstrom, et al Standards Track [Page 10]

/data/webs/external/dokuwiki/data/pages/rfc/rfc1914.txt · Last modified: 1996/02/15 23:01 by 127.0.0.1

Donate Powered by PHP Valid HTML5 Valid CSS Driven by DokuWiki