Tải bản đầy đủ
[Chapter 3] 3.8 Summary

[Chapter 3] 3.8 Summary

Tải bản đầy đủ

[Chapter 3] 3.8 Summary

parameters defined in the Requirements for Internet Hosts RFC. It also provides for dynamic
address allocation, which allows a network to make maximum use of a limited set of
addresses.
Network File System (NFS) is the leading TCP/IP file sharing protocol. It allows server systems to
export directories that are then mounted by clients and used as if they were local disk drives. The
UNIX LPD/LPR protocol can be used for printer sharing on a TCP/IP network.
This chapter concludes our introduction to the architecture, protocols, and services of a TCP/IP
network. In the next chapter we begin to look at how to install a TCP/IP network by examining the
process of planning an installation.

Previous: 3.7 File and Print
Servers
3.7 File and Print Servers

TCP/IP Network
Administration
Book Index

Next: 4. Getting Started
4. Getting Started

[ Library Home | DNS & BIND | TCP/IP | sendmail | sendmail Reference | Firewalls | Practical Security ]

file:///C|/mynapster/Downloads/warez/tcpip/ch03_08.htm (2 of 2) [2001-10-15 09:18:03]

file:///C|/mynapster/Downloads/warez/tcpip/ch03_07.htm

Previous: 3.6 Bootstrap
Protocol

Chapter 3
Network Services

Next: 3.8 Summary

3.7 File and Print Servers
The last two network services, file and print services, make the network more convenient for users.
Not long ago, disk drives and high-quality printers were relatively expensive, and diskless
workstations were common. Today every system has a large hard drive and many have their own highquality laser printers, but the demand for resource-sharing services is higher than ever.

3.7.1 File Sharing
File sharing is not the same as file transfer. It is not simply the ability to move a file from one system
to another. A true file-sharing system does not require you to move entire files across the network. It
allows files to be accessed at the record level so that it is possible for a client to read a record from a
file located on a remote server, update that record, and write it back to the server - without moving the
full file from the server to the client.
File sharing is transparent to the user and to the application software running on the user's system.
Through file sharing, users and programs access files located on remote systems as if they were local
files. In a perfect file-sharing environment, the user neither knows nor cares where files are actually
stored.
File sharing didn't exist in the original TCP/IP protocol suite. It was added to support diskless
workstations. Unlike a proprietary LAN where one vendor defines the official file-sharing protocol,
TCP/IP is an open protocol suite and anyone can propose a new protocol. That's why there are three
TCP/IP protocols for file sharing:
Remote File System
RFS was defined by AT&T for UNIX System V. It is offered on many UNIX systems, but
rarely used.
Andrew File System
AFS is a file-sharing system developed at Carnegie Mellon University. AFS has several
performance enhancements that make it particularly well-suited for wide area network (WAN)
use. AFS has evolved into Distributed File System (DFS). Despite its features, it is not the most

file:///C|/mynapster/Downloads/warez/tcpip/ch03_07.htm (1 of 2) [2001-10-15 09:18:03]

file:///C|/mynapster/Downloads/warez/tcpip/ch03_07.htm

widely used file sharing system.
Network File System
NFS was defined by Sun Microsystems to support their diskless workstations. NFS is designed
primarily for LAN applications and is implemented for all UNIX systems and many other
operating systems.
You will probably use NFS, as it is the most widely used TCP/IP file-sharing protocol. For a detailed
discussion, see Chapter 9.

3.7.2 Print Services
A print server allows printers to be shared by everyone on the network. Printer sharing is not as
important as file sharing, but it is a useful network service. The advantages of printer sharing are:





Fewer printers are needed, and less money is spent on printers and supplies.
Reduced maintenance. There are fewer machines to maintain, and fewer people spending time
fiddling with printers.
Access to special printers. Very high-quality color printers and very high-speed printers are
expensive and needed only occasionally. Sharing these printers makes the best use of expensive
resources.

There are two techniques commonly used for sharing printers on a TCP/IP network. One technique is
to use the network's file sharing services. The other approach is to use the traditional UNIX lpr
command and an lpd server. Print server configuration is covered in Chapter 9.

Previous: 3.6 Bootstrap
Protocol
3.6 Bootstrap Protocol

TCP/IP Network
Administration
Book Index

Next: 3.8 Summary
3.8 Summary

[ Library Home | DNS & BIND | TCP/IP | sendmail | sendmail Reference | Firewalls | Practical Security ]

file:///C|/mynapster/Downloads/warez/tcpip/ch03_07.htm (2 of 2) [2001-10-15 09:18:03]

[Chapter 3] 3.6 Bootstrap Protocol

Previous: 3.5 Configuration
Servers

Chapter 3
Network Services

Next: 3.7 File and Print
Servers

3.6 Bootstrap Protocol
Bootstrap Protocol (BOOTP) is defined in RFCs 951 and 1532. The RFCs describe BOOTP as an
alternative to RARP, and when BOOTP is used RARP is not needed. BOOTP, however, is a more
comprehensive configuration protocol than RARP. It provides much more configuration information
and has the potential to offer still more. The original specification allowed vendor extensions as a
vehicle for the protocol's evolution. RFC 1048 first formalized the definition of these extensions,
which have been updated over time and are currently defined in RFC 2132. BOOTP and its extensions
became the basis for the Dynamic Host Configuration Protocol (DHCP). (More on DHCP later.)
The BOOTP client broadcasts a single packet called a BOOTREQUEST packet that contains, at a
minimum, the client's physical network address. The client sends the broadcast using the address
255.255.255.255, which is a special address called the limited broadcast address. [14] The client
waits for a response from the server. If a response is not received within a specified time interval, the
client retransmits the request. BOOTP uses UDP as a transport protocol and, unlike RARP, it does not
require any special Network Access Layer protocols.
[14] This address is useful because, unlike the normal broadcast address, it doesn't
require the system to know the address of the network it is on.
The server responds to the client's request with a BOOTREPLY packet. BOOTP uses two different
well-known port numbers. UDP port number 67 is used for the server and UDP port number 68 is
used for the client. This is very unusual. Most software uses a well-known port on the server side and
a randomly generated port on the client side. [15] The random port number ensures that each pair of
source/destination ports identifies a unique path for exchanging information. A BOOTP client,
however, is still in the process of booting. It may not know its IP address. Even if the client generates
a source port for the BOOTREQUEST packet, a server response that is addressed to that port and the
client's IP address won't be read by a client that doesn't recognize the address. Therefore, BOOTP
sends the response to a specific port on all hosts. A broadcast sent to UDP port 68 is read by all hosts,
even by a system that doesn't know its specific address. The system then determines if it is the
intended recipient by checking the physical network address embedded in the response.
[15] How and why random source port numbers are used is described in Chapter 1.
The server fills in all of the fields in the packet for which it has data. BOOTP can provide every
file:///C|/mynapster/Downloads/warez/tcpip/ch03_06.htm (1 of 4) [2001-10-15 09:18:04]

[Chapter 3] 3.6 Bootstrap Protocol

essential TCP/IP configuration value. Chapter 9 provides a tutorial on setting up a BOOTP server, as
well as a complete list of all of the configuration parameters that BOOTP can provide. In the next
section we look at DHCP, which is based on BOOTP.

3.6.1 Dynamic Host Configuration Protocol
Dynamic Host Configuration Protocol (DHCP) is defined in RFCs 2131 and 2132. It's designed to be
compatible with BOOTP. RFC 1534 outlines interactions between BOOTP clients and DHCP servers,
and between DHCP clients and BOOTP servers. But interoperability problems are possible; many
network administrators limit DHCP servers to DHCP clients. That's not necessary. See Chapter 9 and
Appendix D, A dhcpd Reference for information on supporting BOOTP clients with DHCP servers.
DHCP uses the same UDP ports, 67 and 68, as BOOTP and the same BOOTREQUEST and
BOOTREPLY packet format. But DHCP is more then just an update of BOOTP. The new protocol
expands the function of BOOTP in two areas:




The configuration parameters provided by a DHCP server include everything defined in the
Requirements for Internet Hosts RFC. DHCP provides a client with a complete set of TCP/IP
configuration values.
DHCP permits automated allocation of IP addresses.

DHCP uses the portion of the BOOTP packet originally set aside for vendor extensions to indicate the
DHCP packet type and to carry a complete set of configuration information. DHCP calls the values in
this part of the packet options instead of vendor extensions. This is a more accurate description
because DHCP defines how the options are used and does not leave their definition up to the vendors.
To handle the full set of configuration values from the Requirements for Internet Hosts RFC, the
Options field is expanded to 312 bytes from the original 64 bytes of the BOOTP Vendor Extensions
field.
You don't usually need to use this full set of configuration values. Don't get me wrong. The
parameters are needed for a complete TCP/IP configuration. It's just that you don't need to define
values for them. Default values are provided in most TCP/IP implementations, and the defaults only
need to be changed in special circumstances. Frankly, you don't need most of the parameters defined
by BOOTP, let alone any additional parameters. The expanded configuration parameters of DHCP
make it a more complete protocol than BOOTP, but they are of only marginal value.
For most network administrators, automatic allocation of IP addresses is a more interesting feature.
DHCP allows addresses to be assigned in three ways:
Manual allocation
The network administrator keeps complete control over addresses by specifically assigning
them to clients. This is exactly the same way that addresses are handled under BOOTP.
Automatic allocation
file:///C|/mynapster/Downloads/warez/tcpip/ch03_06.htm (2 of 4) [2001-10-15 09:18:04]