Resolving Computer Names


The preceding sections pretty much cover the technology for sending data from computer to computer. Next, let's look at how networks find computers by name. (I'll describe the process for TCP/IP. Networks based on the IPX/SPX protocol work in a similar fashion.)

My server's physical network (MAC) address is 00-C0-CA-14-09-2F, but I certainly don't want to know that, let alone type it very often. I just want to view files on the computer named Java. So, it's up to the network software to resolve the name Java into its MAC address 00-C0-CA-14-09-2F so that my computer can send requests to it. How this is accomplished depends on the transport protocol in use: the now-retired NetBEUI, or TCP/IP. The difference between the two is significant.

NetBEUI

I'm sure you've tried to find a friend in a crowded airport lobby. The quickest way to find him or her is to stand up on a chair and shout out his or her name. Works like a charm, even though it momentarily interrupts everyone around you. The old NetBEUI protocol resolved names this way. It broadcast a request to every computer on the network: "Will the computer named Java please send me a message with your MAC address!"

This approach is fine when the desired computer is on the same physical LAN wire; in fact, it's great because it works without any configuration at all. But when two LANs are separated by a WAN link, NetBEUI's technique would require that the broadcast message be sent across the WAN. The WAN link would have to transmit every broadcast on every connected LAN to every other connected LAN to be sure that every computer could be found. Remember that WAN links were historically slow, on the order of 64Kbps, and with a few hundred computers sending a broadcast every minute or so, the WAN link would be fully occupied, carrying only broadcast messages and no useful data.

So, NetBEUI was a bad choice for networks with wide area links, and in fact, Microsoft has dropped support for NetBEUI in Windows XP as better ways have been developed.

IP Name Services and Routing

An Internet Protocol, or IP, based network takes a more sophisticated approach to finding computers by name. To avoid relying completely on broadcasts for name lookups, IP networks rely on a directory service much like the 411 Directory Assistance service for telephones. IP-based protocols send requests for name-to-number lookups to a specific computer, which replies with the required address information. Microsoft supports two name-lookup services: WINS and DNS, which I'll discuss in more detail later on in this chapter.

But this just raises the question of how an IP-based computer can reach the computer hosting the naming service, which might be on a remote network far away. The MAC addresses built into network adapters are essentially random numbers, so knowing a remote computer's MAC address doesn't help you find ityou'd have to broadcast to every computer in the world to locate the destination!

The solution to this problem is that each computer in an IP network is given an IP address, which I'm sure you've seen before; it's a number like 63.69.110.193. These are like street addresses, and can be interpreted by routers all over the world to get data packets where they need to go. As the postal service first sends mail to a given state, then a city, then a street, then your house, so a router only has to know where to deliver data for all IP addresses starting with 63. Once it gets there, the 63 router sends the packet to the router responsible for all addresses starting with 63.69, which sends it to the router for 63.69.110, which finally sends it to computer 63.69.110.193. (I'm way oversimplifying this, but it should give you the picture.)

When data is sent using IP, the sending computer first determines whether the destination computer is on the same physical LAN. If the destination computer is on the same physical LAN, the sending computer uses the old stand-up-and-shout approach: it broadcasts a request for computer number 63.69.110.193 to please identify itself (in IP lingo, it ARPs). The other computer responds with its MAC address, and with that information the network adapter can deliver the packet to its destination.

When the IP address is not a local address, the sending computer forwards the packet to a router, which forwards the packet out across the WAN or the Internet, which is just a very large IP WAN. Routers along the way relay the packet from one router to the next by examining the IP address. The backbone routers of an IP WAN or the Internet know exactly where to send every IP packet, based on its IP address. Eventually, the packet finds its way to a router on the destination LAN, where the router ARPs and sends the packet to its intended computer.

IP Addresses and Network Masks

How does a router or computer tell whether an IP address is local? The answer is in the subnet mask, that mysterious 255.255.255.something number that you've probably entered into at least one home computer to connect to the Internet.

An IP address is a series of four numbers between 0 and 255. It can be written in binary as a 32-bit binary number, as in this example:

 11000110 01000110 10010010 01000110 

A network mask can also be written in binary; for example, 255.255.255.240 is

 11111111 11111111 11111111 11110000 

The part of an IP address that lines up with the ones in its subnet mask is called the subnet number, and the remainder is the node number or node address.

IP address

11000110 01000110 10010010 01000110

subnet mask

11111111 11111111 11111111 11110000

subnet number

11000110 01000110 10010010 01000

node number

110


Every computer on an IP LAN must have the same subnet number. If the subnet number of a destination IP address matches the sender's subnet number, the address is local: shout, get the MAC address, send directly. If the subnet number differs, the computer simply punts: It sends the packet to a designated gateway, a router whose job it is to ultimately deliver the packet.

TIP

You probably suspect that this description is an oversimplification. It's not, actually, for the simple case I've described. What I've left out are details about how routers decide which of several possible directions to send a given packet and how they communicate new routes and traffic reports to each other. For a detailed look at the IP protocol and network technology, you might check out the following books:

Practical Cisco Routers, ISBN: 0-7987-2103-1, Que

Upgrading and Repairing Networks, Fourth Edition, ISBN 0-7897-2817-6, Que


NOTE

If you're interested in the nitty-gritty details of Microsoft's implementation of network protocols, including TCP/IP timing, tuning, and Registry entry details, you might want to dig into the technical whitepapers at http://www.microsoft.com/Windows2000/techinfo.


DHCP and IP Addressing

As I mentioned earlier, a network card's MAC address is physically "burned in" to the adapter's hardware. But IP addressing must somehow be set up in software. We can't just pull a number out of a hat, because each computer on a LAN must use a number with the same subnet number and network mask, but a different node number than others on its local network. Also, it needs to know the address of its local gateway router, and the addresses of any name-resolving servers.

There's no simple automatic way for a computer to reliably determine this information. It can be assigned and entered manually, but on large networks, this is a cumbersome and difficult task.

To solve this problem the Internet community developed a protocol called BootP. Microsoft "embraced and extended" the BootP protocol and called the result DHCP (Dynamic Host Configuration Protocol). DHCP service can be provided by Windows 200x Server (as well as NT Server), the Internet Connection Sharing service, as well as virtually all routers and hardware Internet connection sharing devices.

When a computer using DHCP is started (booted) up, it broadcasts a request for an IP address on its local network. A computer running a DHCP server responds to this request with a reply packet that specifies an appropriate IP address, network mask, and other setup information. Since broadcasts aren't passed by routers to other connected networks, only the local DHCP server hears the request and responds with an appropriate local network address. Each DHCP server keeps track of which IP addresses it has assigned to local computers, to avoid handing out the same number twice. It's also responsible for recycling addresses when a computer leaves the network and stops using an address it's been given. So, it places a time limit on which a computer can use a given IP addressit's called a lease. Before the time limit runs out, the computer must contact the DHCP server to either renew its lease, or obtain a new number.

NOTE

Just when you thought things couldn't get more complex… they do. Small IP-based LANs with only Windows computers don't even really need a DHCP server. If Windows is set up for automatic (DHCP) IP configuration, and no DHCP server responds to the request for configuration information within 30 seconds or so, it does pull an IP address out of a hat. It picks a random IP address in the range 169.254.0.0 through 169.254.255.255.

Windows continues to ask for DHCP service every three minutes, and if a DHCP response does eventually arrive, Windows reconfigures itself accordingly.

Although this works, it's ugly: The boot process is delayed a while, and every three minutes the network will seem to "lock up," over and over. The fix is to manually assign IP addresses in each computer.


Some people move their computers between networks with DHCP and static setups. This is especially common with laptop computers that commute between home and office. Office networks usually use DHCP, while home networks can be set up either way. Older versions of Windows had to be configured for one network and then had to be completely reconfigured (manually) for the other every time they were moved. If you're a commuter, you'll be happy to know that Windows XP Professional has a feature called Alternate Configuration, which lets you set up static IP information to be used when DHCP isn't present. This lets you more easily move between multiple networks, as long as only one has a static IP setup.

Windows Networking and TCP/IP

To return the discussion to name resolution, let me describe how a TCP/IP network turns names into addresses. Two name resolution systems can be involved: WINS and DNS.

WINS

The Windows Internet Naming Service, or WINS, was introduced with Windows NT, which was the first Microsoft operating system that allowed Microsoft File Sharing to operate over the TCP/IP protocol. Windows users are used to using one-word names to identify computers, and networks can contain computers using NetBIOS and IPX/SPX as well as the TCP/IP protocol. Microsoft developed WINS as an integrated address resolution system. It learns the names of all the computers connected to each network connected to the server running WINS and makes these names available to TCP/IP-based computers on those networks. When a new computer appears on the network, the computer registers itself with the WINS server so that other computers can find it by name.

More importantly, WINS servers trade information across a WAN or the Internet, making name service available out of the reach of NetBEUI-based computers. The addition of WINS and TCP/IP to Microsoft networking made file sharing across a WAN a much more efficient operation, as it removed the requirement for bridging NetBEUI packets across a WAN link.

It works like this: A WINS server can respond to broadcasts ("Will a WINS server please tell me the address of the computer named Java?"), but on a large network, you can also tell Windows to direct its request to a specific WINS server at a particular IP address. This way, a TCP/IP-based client can find computers across a WAN link, through TCP/IP's capability to efficiently route directly addressed packets from network to network, without the need to send broadcast packets across the link as well.

TIP

Windows XP supports WINS, but it's no longer really necessary. When you use Windows XP or Windows 2000 Server to manage the network, Windows can use the standard Internet-style DNS system to locate network resources.


DNS

Domain name service, or DNS, is the name resolution system used by all Internet-based software, and now on most Windows 200x Server networks as well. The domain name service is a sort of distributed database system that looks up names like www.quepublishing.com and returns IP addresses like 198.70.146.70. It also provides Inverse DNS information, which tells you that IP address 63.69.110.193 is named www.quepublishing.com.

You can use DNS-based naming with Microsoft Networking, too. For example, you can tell Windows Explorer to view \\server.mycompany.com. Windows tries WINS first, if it's set up, and then attempts to resolve the name using DNS. If DNS fails, Windows broadcasts a request to the local LAN. If one of these methods succeeds, Windows can go ahead and use Microsoft File Sharing to connect to the computer.

Because corporate networks are growing so large, the old "one word name" scheme for Windows networks is no longer adequate. On Windows 200x Server-based networks, Microsoft is encouraging the use of DNS-like names (such as host.region.company.com) even inside a company's network. Microsoft is making this use easier by tying the Windows 200x Server DNS service into the Active Directory, which identifies all of the network's computers, networks, users, and resources.

DNS was designed for the original 1970s' Internet with its fairly static database; entering new computers and domains was time-consuming. The DNS server provided with Windows 200x Server, however, interacts with the Microsoft networking system on a dynamic basis to learn the names of computers as they plug into and leave the network.



Special Edition Using Microsoft Windows XP Professional
Special Edition Using Microsoft Windows XP Professional (3rd Edition)
ISBN: 0789732807
EAN: 2147483647
Year: 2003
Pages: 450

flylib.com © 2008-2017.
If you may any questions please contact us: flylib@qtcs.net