As per Relevance of the word distribute, we have this rfc below:
RFC: 756 July 1979
The NIC Name Server--A Datagram Based Information
John R. Pickens, Elizabeth J. Feinler, and James E.
July 1979
SRI
Telecommunications Sciences
333
Menlo Park, California 94025
(Also published in Proceedings of the Fourth Berkeley
on Distributed Data Management and Computer Networks)
NIC Name Server July 1979
In this paper a new method for distributing and updating
name/address information in large computer networks is described
The technique uses datagrams to provide a
transaction-based query/response service. A provisional
is being provided by the Arpanet Network Information Center (NIC
and is used by mobile packet radio terminals, as well as
several Arpanet DEC-10 hosts. Extensions to the service
suggested that would expand the query functionality to allow
flexible query formats as well as queries for service addresses
Several architectural approaches with potential for
into a distributed internet environment are proposed.
technique may be utilized in support of other
applications such as user identification and group
for computer based mail
1.
In large computer networks, such as the Arpanet [1],
network-wide standard host-addressing information must
maintained and distributed. To fulfill that need, the
Network Information Center (NIC) at SRI International
maintained, administered, and distributed the host
data base to Arpanet hosts since 1972 [2].
The most common method for maintaining an up-to-date copy
each host is to bulk-transfer the entire data base to each
individually. This technique satisfies most host
needs on the Arpanet today. However, some hosts maintain
a complete nor a current copy of the data base because of
memory capacity and infrequent processing of updates.
addition, with the expansion of the Arpanet into the
environment [3, 4], a strong need has arisen for new
to augment the distribution of name/address information
One method currently being investigated is the
distribution of host-address information via a transaction-based
inquiry-response process called the Name Server [5, 6].
support this investigation, the NIC has developed a
Name Server that is compatible with a level of service
in the Defense Advanced Research Projects Agency (DARPA)
experiment [5]. The basic Name Server is described in this
and a set of additional functions that such a service might
expected to support is proposed
The discussion is structured as follows: Section 1
the NIC Name Server and how it is derived from the NIC data
service. Section 2 describes extensions of the name server
allow a richer syntax and queries for service addresses.
SRI International [Page 1]
July 1979 NIC Name
3 discusses architectural issues, and presents some
thoughts on how to evolve from the current centralized
hierarchic service to a distributed Name Server service
2. THE NIC NAME
A Name Server service has been installed on SRI-KA, an
DEC-10. Inquiry-response access is via the Internet Name
protocol [5], which in turn employs the DARPA Internet Protocol
IP4 [7].
To demonstrate the service a simple interactive facility
provided to format user input into name server requests--e.g.
query of the form !ARPANET!FOO-TENEX returns an address such
"10 2 0 9" (NET=10, HOST=2, LOGICALHOST=0, IMP=9; for details
host address formats see [8]).
User access to the name server has been implemented on
Arpanet DEC-10 TENEX and Packet Radio Network LSI-11
Interface Unit (TIU) hosts [9, 10]. While the TENEX
serves primarily as a demonstration vehicle, the LSI-11
provides a valuable augmentation of the TIU's host table.
typical scenario is that when the packet radio TIU is
or initialized, it contains only a minimal host table, with
addresses of a few candidate name servers. The user queries
name server with a simple manual query process, and then uses
address obtained to open a TELNET connection to the desired host
The information to support the name server originates from
NIC's Arpanet host address data base. An optimized version
this data base is presented to the name server upon
initiation as an input file
3. NAME SERVER
The basic name server provides a simple address-binding
[5]. In response to a datagram query [7, 11], the name
returns either an address, a list of similar names if a
match is not found, or an error indication. Several
additional functions can be envisioned for the name server
as service queries and broader access to host-
information
3.1. Similar
An important issue to be resolved is that of the
given to the "similar names" response. A standard
should be given and not be left to implementors' whims
[Page 2] SRI
NIC Name Server July 1979
If the "similar names" response is used primarily to
helpful information to a human-interface process, then it may
useful to model the behavior of the name server on the
of other known processes that present host name information
demand. An example of this is a common implementation of
terminal access on the Arpanet, User TELNET [12], in which
different functions occur
1. Upon termination of host name input (e.g. ),
user is warned only with an audible alarm if the
used is not unique. If the name is unique, the name
completed, and the requested operation is initiated
2. In response to , either the name will be
if unique or the user will be warned with an
alarm if the name is not unique
3. Only in response to "?" will a list of similar names
printed. "Similar names", in this case, means
names that begin with the same character string.
list is alphabetized
In support of this style of user interface, it may
appropriate to return the "similar names" response only
requested. Two ways to achieve this might be either to set
option bit or to use "?" to force the similar names response
3.2. Query
A second issue in the provision of name server service is
of query syntax. The basic level of service previously
allows only a few query functions. With more intelligent
servers, complex queries can be supported
The current Internet name server requires two fields in
query string--a network name field and a host name field. If
network field is non-existent, a local network query is assumed
Since network independent queries are desirable, an
query functionality must be specified. One way this might
done is to add to the notion of "missing field", which
"local", the notion of a special character like "*", which
"all".
The semantic range of queries afforded by adopting
convention is listed below (Note: ~ is used to mean "null".
both network and host fields are null the representation is "~
~". "N" means "network" and "H" means "host"):
SRI International [Page 3]
July 1979 NIC Name
~ ~ local net, local host (validity check?)
~ * local net, all
~ H local net, named
* ~ all nets, local host (inverse search
* * all nets, all hosts (probably prohibited
* H all nets, named
N ~ named net, local host (inverse search
N * named net, all
N H named net, named
By combining the on-demand similar-names function, "all"
"local", and by allowing "*" to be prefixed or appended to
query string as a wild card character, one can query as follows
~ SRI*? All hosts named SRI* on local
* SRI*? All hosts named SRI* on all
* *UNIX*? All hosts named *UNIX* on all
3.3. Service
It has been suggested that the name server be generalized
a binding function [13, 14]. In this context, allowing
queries is a very useful extension. One application of
service, that exists within the Packet Radio Project at SRI,
the need to find the addresses of Hosts that support
LoaderServer service--a service that allows packet radio TIUs
receive executable programs via downline loading
Service querying, unlike host names querying, requires
multiple response capability. The querying process would,
receiving multiple service descriptors, attempt to
access to each service, one at a time, until successful
Service descriptors consist of an official name, a list
alias names, and a network-dependent address. In the case
Arpanet Internet services, this address field would consist
the host address(32 bits), port(32 bits), and protocol number(8
bits). For Arpanet NCP services, the address would consist of
host address(24 bits) and a socket(32 bits).
[Page 4] SRI
NIC Name Server July 1979
Syntactically, service queries can be derived from host
by the addition of a service name field, as below
NET HOST
A network-independent service query, for example, can
represented as
* *
3.4. Name Server
The concept of options has been introduced in the discussion
the "similar names" function. Another group of options may
used to specify the format of the reply. At one extreme is
compact, binary, style such as exists in the basic level
service. At the other extreme is an expanded, textual,
such as is represented by a NIC host table record with
and alias names included. Options can be envisioned
specify
- Binary versus text
- Inclusion of each field in the
- Inclusion of official name, per field, in the
- Inclusion of alias names, per field, in the
- Inclusion of other miscellaneous information, such
operating system, machine type, access restrictions
and so on
Other options can be envisioned that specify the scope of
search, such as "find SERVER hosts only". An alternate form
specifying formats might be to settle on several standard ones
and allow an option to select among them
Certainly, not all name servers can support all such options
and not all options are equally useful. Thus, the proposed
will be expanded or contracted to fit the actual needs
processes using the name server service
3.5. MORE DATA
It should be noted that some of the proposed name
extensions have the potential for generating more than a
datagram's worth of reply, since the current DARPA
Protocol limits the size which all networks must support to 576
octets [15]. In spite of this, the size of such replies need
require a full-blown stream protocol. Several
SRI International [Page 5]
July 1979 NIC Name
exist
1. Disallow options that imply large replies
2. Truncate the packet for large replies
3. Ignore the recommended maximum datagram size
4. Utilize an alternate base protocol for such requests
5. Develop a MORE DATA protocol
If alternative 1 is chosen, the potential for overflow exists
even with the basic level of service. Alternative 2
unpredictable behavior to the user of the name server service
Alternative 3 reduces the availability of the service
Alternative 4 is certainly possible, but may be overkill
Alternative 5 appears to be a reasonable solution and could
implemented very simply. The name server could return, as
of the reply, a code of the following form
+------+---------+
| MORE | ID_NEXT |
+------+---------+
where ID_NEXT is a name-server-chosen quantity that allows
name server to find the next block of reply, the next time it
queried. This quantity may be an internal pointer, a
number, or whatever the name server chooses. Follow-on
may be implemented by recomputing the entire original query
discarding output until the ID_NEXT block is reached, or
efficiently storing the entire reply in a cache, fragmented
blocks (with appropriate decay algorithms).
3.6. Dynamic
In the previous discussion, the host name data base was
to have been a static or slowly changing entity with
administrative and manual update authority. This model
most of the network needs in the Arpanet and
communities. However, dynamic automated updating of the
table may be needed in the future, especially in
environments such as the Packet Radio Network
In a closed user group community (such as a local network
mutually trusting hosts), dynamic updating becomes simply
technical question concerning packet formats. In
communities, a mechanism to authenticate the change request
be developed; however, the authentication issue is outside
scope of this paper
[Page 6] SRI
NIC Name Server July 1979
4.
The Name Server concept is invaluable for allowing hosts
incomplete knowledge of the network address space to obtain
access to network services. Whether for reasons of
kernel space or of dynamically changing environments, the
for the service is little questioned. However,
design issues revolve around the methods for providing
service and for administering and updating the data base
In the current NIC Name Server, the service is centralized,
is supported by a data base administered by a single authority
In the long range, other architectures are possible that
more flexible ways to distribute host information within
between networks and administrative entities. These
opportunities for dynamic, automated, approaches to
maintenance and sharing of data--particularly host name data
From an evolutionary point of view, initial Name
services will likely exist as a centralized service,
with one large Name Server that has knowledge of
networks. From this beginning, an expansion in two
directions can be envisioned
- In the direction of internal distribution, the
server can be partitioned into multiple,
processes on separate hosts. The data base can
replicated exactly or managed as a distributed
base
- In the direction of administrative distribution
multiple autonomous name servers may exist
exchange data in an appropriate fashion, on a
network or other administrative basis
For hosts with small host tables, caching might be used
whereby local, temporary copies would be maintained of subsets
the addressing data base. Such copies may be obtained either
remembering previous queries made of name servers, or
receiving automatic distributions of data from name servers.
mobile hosts, in which even the home network is unknown, it
be possible to maintain a very sparse table with the addresses
only a few name servers
For hosts lacking even the knowledge of name server addresses
a very primitive name server function can be provided by
network hosts that would allow real name servers to be located
e.g., a query of the form "* * RealNameServer" addressed to
arbitrarily selected host could elicit the address of a real
Server
Finally, the possibility exists for multiple name servers
communicate dynamically in attempting to resolve queries. If
SRI International [Page 7]
July 1979 NIC Name
for example, a name server on the Arpanet receives a query for
host on the Packet Radio Network, then the Arpanet name
can conceivably query the Packet Radio Network Name Server
resolve the reply
5. FUTURE
The techniques discussed in this paper for providing
access to and maintenance of host address information
generally applicable to other information-providing services
Two possibilities currently under investigation at SRI
user identification servers [16] and time servers, which
people/address and time-stamp information, respectively,
datagram driven information utilities
Further work is needed to refine the implementation of the
server and its using query processes. Two items in
are direct system calls into the NIC data base management
for general access to host information and process-level
interfaces for using processes. The design issues for
implementation are complex and involve some trade-offs. The
obvious trade-off is volume of network traffic versus "freshness
of information. The local host table handler can either send
message to the name server for every address request, or it
use some type of local cache to remember frequently
names. SRI is exploring both the process-level interface for
LSI-11 TIU and the problems of local host table management
small machines operating in a dynamic environment
Information services such as the Name Server are
components of distributed systems and applications. However,
effective utilization of such services is a relatively
and unexplored area. One area in which SRI plans to study
impact on distributed architectures is in computer based
applications. Information utilities in this environment
range from the support of simple mailbox address queries
complex address list management needed for inter-
and group resolution
6.
A provisional Name Server service, based on the NIC
address data base was described in this paper. In addition,
collection of design ideas for an internet Name Server
has been presented
Work is continuing on the refinement of the NIC name
service. New requirements and opportunities for
distribution are being investigated. Many questions have
[Page 8] SRI
NIC Name Server July 1979
raised in exploring an expansion of the existing service. Such
expansion is expected to result in more useful support
internet (and intranet) capability
1. L. G. Roberts and B. D. Wessler, "Computer
Development to Achieve Resource Sharing," in Proceedings
SJCC, pp. 543-549 (AFIP, 1970).
2. M. D. Kudlick and E. J. Feinler, Host Names On-line,
608, Stanford Research Institute, Menlo Park,
(January 1974).
3. V. G. Cerf and R. E. Kahn, "A Protocol for Packet
Interconnection," IEEE Transactions on
Technology, Vol. COM-22, pp. 637-641 (1974)._
4. V. G. Cerf and P. T. Kirstein, "Issues in Packet-
Interconnection," Proc. IEEE, Vol. 66, No. 11, pp
1386-1408 (November 1978).
5. J. Postel, Internet Name Server, IEN 89,
Sciences Institute, Univ. of Southern Calif., Marina
Rey, California, May 1979.
6. J. R. Pickens, E. J. Feinler and J. E. Mathis,
Experimental Network Information Center Name
(NICNAME), IEN 103, SRI International, Menlo Park
California (May 1979).
7. J. Postel, Internet Protocol, IEN 81, Information
Institute, Univ. of Southern Calif., Marina Del Rey
California (February 1979).
8. J. Postel, Address Mappings, IEN 91, Information
Institute, Univ. of Southern Calif., Marina Del Rey
California (May 1979).
9. R. E. Kahn, "The Organization of Computer Resources into
Packet Radio Network," IEEE Transactions on Communications
Vol. COM-25, No. 1, pp. 169-178 (January 1977).
10. R. E. Kahn, S. A. Gronemeyer, J. Burchfiel, and R. C
Kunzelman, "Advances in Packet Radio Technology," Proc
IEEE, Vol. 66, No. 11, pp. 1468-1496 (November 1978).
11. J. Postel, User Datagram Protocol, IEN 88,
Sciences Institute, Univ. of Southern Calif., Marina
Rey, California (May 1979).
SRI International [Page 9]
July 1979 NIC Name
12. E. Leavitt, TENEX USER'S GUIDE, Bolt Beranek and Newman
Inc., Cambridge, Massachusetts
13. R. Bressler, A Proposed Experiment With a Message
Protocol (section on Information Operator), pp. 26-31,
333, Bolt Beranek and Newman Inc, Cambridge, Mass. (May 15,
1972).
14. Y. Dalal, Internet Meeting, January 24,25 1979, (
Discussion).
15. J. Postel, Internet Meeting Notes - 25,26 January 1979, pp
12, IEN 76, Information Sciences Institute, Univ.
Southern Calif., Marina Del Rey, California (
1979).
16. E. J. Feinler, "The Identification Data Base in
Networking Environment," in NTC '77 Conference Record, pp
21:3 (IEEE, 1977).
[Page 10] SRI
NIC Name Server July 1979
Table of
1. INTRODUCTION 1
2. THE NIC NAME SERVER 2
3. NAME SERVER ISSUES 2
3.1. Similar Names 2
3.2. Query Syntax 3
3.3. Service Queries 4
3.4. Name Server Options 5
3.5. MORE DATA Protocol 5
3.6. Dynamic Updates 6
4. ARCHITECTURE 7
5. FUTURE WORK 8
6. CONCLUSION 8
REFERENCES 9
SRI International [Page i
if you see any problems within the linking, don't worry be happy,
this is version 0.1 of the Relevance System and you gotta expect some crappy subroutines sometimes,
just be content we did not write this in Java, which would have made this "bigger and better" HAHAHHA.
RFC documents can be found at I.E.T.F.
Relevance System Copyright © 2002 Spectrum WorldResearch
other technical nosh by ServerMasters Corporation
collaboration of BobX
