IP’s 32-bit addressing scheme allows for a great deal of flexibility, but these addresses are extremely difficult to work with on a continuing basis. It is much easier to work with system "names" than it is to work with raw IP addresses.
Also, IP addresses can and do change quite often. By using the name of the system instead of the IP address, you are shielded from these changes. As long as the network administrator makes the relevant changes to their naming service – and you are connecting to that system using its name instead of its address – then you will never even realize that the system’s address has been changed.
There are two basic types of naming services in use on IP networks today. The first uses a local text file database called "HOSTS" to provide a name-to-address mapping service. Almost every IP system supports the use of HOSTS files. Whenever you request a connection to a host name, the application you are using will use the HOSTS file to locate the underlying IP address of the destination host, and then establish a connection.
The HOSTS file concept works well for a few devices on a local network, but does not work well for more than a dozen or so systems. Because the files are local to each system, adding a new system to each system’s HOSTS file adds exponentially more effort. For example, adding a 13th system to a network requires that you add that system to 12 different HOSTS files. Adding a 14th system requires that you add that system to 13 different HOSTS files, and so forth.
This architecture would simply not work with the millions of devices on the global Internet, and does not work well for most organizations’ internal networks either. Instead, these networks rely on a distributed naming service called the Domain Name System (DNS). DNS allows a client system to query a name server for address information. Under this model, administrators only have to manage the name-to-address database in one location (at the DNS server). All changes to this database take effect almost immediately, allowing for dynamic updates to the network to be implemented with no additional effort being required by the clients.
You may need to discuss this subject with other system administrators, consultants, or service providers in order to determine a hostname for this server, and also to locate any DNS servers in use within your organization.
You will need to collect information about the NetWare server as well as the naming services in use on your network, in order to successfully configure TCP/IP and Unoverica Message Transport. This information will be determined by a variety of factors:
For more information on HOSTS files and DNS, refer to Appendix C: Name Resolution Services.
STEP: To continue to the next step in the configuration process, go to section 2.3 Configuring and Starting TCP/IP.
Copyright 1997 Unoverica Corporation, All Rights Reserved page
Send comments to docs@unoverica.com