Practical TCP/IP and Ethernet Networking- P33 doc

5 206 0
Practical TCP/IP and Ethernet Networking- P33 doc

Đang tải... (xem toàn văn)

Thông tin tài liệu

142 Practical TCP/IP and Ethernet Networking 2 Reconnection 3 Suppress go ahead – i.e. no longer send go-ahead signal after data 4 Approximate message size negotiation 5 Status request – used to obtain the status of a TELNET option from the remote machine. 6 Request timing mark – used to synchronize the two ends of a connection 7 Remote controlled transmission and echo 8 Output line width 9 Output page length 10 Output carriage-return action 11 Output horizontal tab stop setting 12 Output horizontal tab stop action 13 Output form feed action 14 Output vertical tab stop setting 15 Output vertical tab stop action 16 Output line feed action 17 Extend ASCII characters 18 Logout 24 Terminal type – used to exchange information about the make and model of a terminal being used 25 End of record – sent at end of data 28 Terminal location number 31 Window size 34 Line-mode – uses local editing and sends complete lines instead of individual characters. The two-octet sequence may be followed by a third octet containing optional parameters. An optional code of 1 indicates ‘ECHO’; therefore, the three octets sequence 255-251-1 means ‘WILL ECHO’ and instructs the other end to begin echoing back the characters that it receives. A command sequence of 255-252-1 indicates that the sender either will not echo back characters or wants to stop echoing. The negotiation of options allows clients and servers to optimize their interaction. It is also possible for newer versions of TELNET software that provide more options to work with older versions, as only the options that are recognized by both ends are negotiated. If the server application malfunctions and stops reading data from the TCP connection, the operating system buffers will fill up until TCP eventually indicates to the client system a window size of zero, thus preventing further data flow from the client. In such a situation TELNET control codes will not be read and therefore will have no effect. To bypass the normal flow control mechanism, TELNET uses an ‘out of band’ signal. Whenever it places a control signal in the data stream, it also sends a SYNCH command and appends a data mark octet. This induces TCP to send a segment with the URGENT DATA flag set, which reaches the server directly and causes it to read and discard all data until it finds the data mark in the data stream, after which it returns to normal processing. TELNET programs are freely available and can be downloaded through the Internet. Windows 95/98 includes a simple TELNET program called Microsoft TELNET 1.0. Application layer protocols 143 Figure 8.5 TELNET login (courtesy of Microsoft Corporation) 8.5 RLOGIN (remote login) The Rlogin service is related to TELNET but is typically used in a UNIX environment. In the case of TELNET, a user at any type of TCP/IP host can log into any other type of TCP/IP host. The local host and remote host may be running totally different operating systems. Rlogin, on the other hand, is normally used when a user at a local UNIX host wants to log into a remote UNIX host. Rlogin is somewhat easier to use than TELNET and provides a few additional services. For example, it allows the user to maintain a list of hosts in a rhosts file so the user does not have to enter a user name and password at the time of each login. 8.6 NFS (network file system) NFS was originally created by SUN Microsystems to share resources (files and directories) among hosts running UNIX with a local host in such a way that all resources seem to be resident on the local host. Because of its popularity implementations have been created on other operating systems such as UNIX, OS/2, Microsoft Windows and NetWare. Say that a company stores all of the company sales reports on computer sales1. Users from the marketing department wish to access those reports from their computer, market1, without having to log in into sales1, or copy everything from one machine to the other. Both computers are connected together on the same TCP/IP network and both have NFS installed and running. The reports are contained in the sales/reports directory on the sales1 computer. To share the sales reports, the administrator from sales1 types the following command: share -F nfs/sales/reports This command makes the sales/reports directory available to any other computer on the network that can access sales1. The -F option identifies the resource being shared as an NFS file system. Other options could be used to restrict access to certain computers and to allow read/write or read-only access. 144 Practical TCP/IP and Ethernet Networking On the computer named market1, the system administrator decides to connect the reports directory to the directory called usr2/salesrpt locally using this command: Mount -F nfs sales1:/sales/reports/usr2/salesrpt Once the directory is mounted users can: • Change to the /usr2/salesrpt directory, list the content, open the files and use any standard commands to access and work with the local files • Move down and search the subdirectories beneath the mount point on the remote system • Run applications stored on remote file system so that they run as any other application on the local system • Access the files and directories based on standard UNIX file system permissions 8.7 DNS (domain name system) 8.7.1 Name resolution using hosts files In small TCP/IP internetworks hosts are typically given simple names such as computer1. The mapping between these host names and their associated IP addresses is then maintained as a ‘flat’ database in a local file (the hosts file) on each host. The resolver process on each host translates host names into IP addresses by a simple lookup procedure. In a large network the maintenance of the hosts files, which have to be identical for all hosts and continuously updated in order to reflect additions and changes, can become quite a tedious task. On the Internet, with millions of names, this becomes impossible. 8.7.2 Name resolution using DNS The domain name system (DNS) provides a network-wide (and in the case of the Internet – a world-wide) directory service that maps host names against IP addresses. For most users this is a transparent process and not relevant whether the resolution takes place via a hosts file or via DNS. When the IP address of a specific destination host has to be resolved, the DNS resolver on the source host contacts a DNS server somewhere on the internetwork. There is usually more than one DNS server, and the database may be distributed among them. Where an individual DNS server does not have access to the entire database, the host’s name resolver may have to contact more than one DNS server, or the DNS servers may exchange information amongst themselves in order to resolve the query. Each DNS name server maintains a tree-structured directory database. The collective database stored on all the DNS servers forms a global namespace of all the hosts that can be referenced anywhere on the internetwork. The Internet naming scheme hierarchical namespace The original Internet namespace was ‘flat’ i.e. it had no hierarchical structure. At this stage it was still administered by the Network Information Center (NIC). The task eventually became too large because of the rapidly increasing number of hosts and a hierarchical (tree-structured) namespace was adopted. At present, the ultimate responsibility for the maintenance of this namespace is vested in the Internet Assigned Names Authority (IANA). Application layer protocols 145 In a domain name, the most local domain is written first and the most global domain is written last. The domain name purdue.edu might identify Purdue University. This domain name is registered against a specific IP address. The administrator of this domain name may now create sub-domains such as, say, cs.purdue.edu for the computer science department at Purdue University. The administrator of the computer science department, in turn, may assign a fully qualified domain name (FQDN) to an individual host as follows: computer1.cs.purdue.edu If a user is referring to a specific host within a local network, a FAQN is not needed, as the DNS resolver will automatically supply the missing high-level domain name qualifier. The following commands are therefore equivalent when the ftp client and ftp server are located on the same network: • ftp computer1.purdue.edu • ftp computer1 Standard domain names The original namespace contained a set of standard top-level domains without any reference to a specific country. Since the original Internet was not envisaged to exist beyond the borders of the United States, the absence of any reference to a country implies an organization within the USA. The following are some of the common top-level domains administered by IANA. More detailed information can be obtained from www.iana.org. • .com Commercial organizations • .net Major network support centers • .edu Educational institutions • .gov Government institutions (United States government only) • .mil Military groups (United States military only) • .int Organizations established by international treaties between governments, or Internet infrastructure databases • .org Organizations other than the above Domain names for the .com, .net and .org domains can be obtained from the following registrar web sites: • CORE • Melbourne IT • Network Solutions (a.k.a. NetSol) • Oleane (France Telekom) • Register.com Domain names for the .EDU domain are registered only through Network Solutions. Country codes As the Internet backbone was extended into countries other than the USA, the top-level domain names were extended with a two-letter country code as per ISO 3166 (e.g. uk for the United Kingdom, au for Australia, za for South Africa, ca for Canada). The complete list of all Country Code Top-Level Domains (CCTLDs) can be obtained from the IANA website (www.iana.org). This site also contains the basic information for each CCTLD such as the governing agency, administrative and technical contact names telephone and 146 Practical TCP/IP and Ethernet Networking fax numbers, and server information. This information can also be obtained from the Network Solutions web site (www.netsol.com). DNS clients and servers Each host on a network that uses the DNS system runs the DNS client software, which implements the resolver function. Designated servers, in turn, implement the DNS nameserver functions. In processing a command that uses a domain name instead of an IP address, the TCP/IP software automatically invokes the DNS resolver function. The resolver then accesses one or more nameservers in order to obtain the relevant IP address. On a small network, one nameserver may be sufficient and the nameserver software may run on a machine already used for other server purposes (such as a Windows NT server acting as a file server). On large networks it is prudent to run at least two nameservers for reasons of availability, viz. a primary and a secondary nameserver. On large internetworks it is also common to use multiple nameservers, each of which contains a portion of the namespace. It is also possible to replicate portions of the namespace across several servers in order to increase availability. A network connected to the Internet needs access to at least one primary nameserver and one secondary nameserver, both capable of performing naming operations for the registered domain names on the Internet. In this case, the number of domain names is so large that the namespace is distributed across multiple servers, called authoritative servers, in different countries. For example, all the co.za domain names (i.e. South African Company names) may be hosted on one or more nameserver(s) located in South Africa. Name resolution A resolver on a host in Canada requiring the IP address for www.hp.co.za in South Africa, will contact its designated DNS server (wherever it may be), which in turn will contact the relevant authoritative server(s) located in South Africa in order to obtain the IP address. There are two methods by which the interaction between DNS resolver and nameserver can take place. With recursive resolution, the DNS client makes the initial request. The burden of the processing is then borne by the server, who may have to contact other servers before eventually passing the result back to the client. This is typical for smaller hosts such as PCs and laptops. With iterative recursion, the resolver contacts a server that either provides the answer, or refers the resolver to another nameserver. This process is repeated until the resolution process is completed. The computational burden is shared between resolver and nameservers. This is typical for larger computers and mainframes. The DNS client resolver software can implement a caching function by storing the results from the name resolution operation. In this way the resolver can resolve a future query by looking up the cache rather than actually contacting the nameserver. Cache entries are given a time to live so that they are purged from the cache after a given amount of time. . such as the governing agency, administrative and technical contact names telephone and 146 Practical TCP/IP and Ethernet Networking fax numbers, and server information. This information can. options could be used to restrict access to certain computers and to allow read/write or read-only access. 144 Practical TCP/IP and Ethernet Networking On the computer named market1, the system. at any type of TCP/IP host can log into any other type of TCP/IP host. The local host and remote host may be running totally different operating systems. Rlogin, on the other hand, is normally

Ngày đăng: 04/07/2014, 08:21

Từ khóa liên quan

Tài liệu cùng người dùng

Tài liệu liên quan