Windows Internet Name Service
Windows Internet Name Service |
|
The performance of a WINS system depends on other traffic in the network. When the WINS server is not on the local subnet but is somewhere on the WAN, server requests and responses must go through router queues, causing delays at peak times. Even during replication, bulk transport gets its fair share of the network bandwidth.
The messages described later in this section are UDP/TCP messages. Before they can be sent, the physical address, or media access control (MAC) address must be known. If the IP address is already in the ARP cache, the WINS message generates no new ARP message. Otherwise, the client machine will send an ARP packet to resolve the MAC address from the destination IP address, if the destination is on the same local subnet, or from the IP address of the gateway, if the destination is on a remote subnet. Registrations are usually done in groups. Only one ARP message is required per group; this message is not WAN traffic.
All message sizes given in this section are for the messages without a scope ID. The message sizes described here are for Ethernet. On token ring, FDDI, WAN, and so on, the headers (and therefore the total length) vary.
WINS clients generate the following four basic messages:
These four messages are discussed in more detail in "WINS Clients" in this chapter.
A Windows 2000–based WINS client usually registers more NetBIOS names than other WINS-enabled clients. The name registration requests generated by a Windows 2000–based computer include the following:
When a WINS-enabled client starts on the network, it sends a name registration request for the Workstation service, the Server service, the Messenger service, and any additional Microsoft network services running on the computer. In other words, when a WINS client starts on the network, it generates a minimum of three name registration requests and three entries in the WINS database.
A name registration request is sent for every NetBIOS name that an application uses. The application makes the request when it (often implemented as a service) starts, which is usually when the computer starts. For a client, the minimum number of names is the two computer names (one for the workstation component with a last byte of <00> and one for the messenger with a last byte of <03>); the domain name; and the user name (messenger name, last byte <03>).
A server usually has additional names, including server name (the same as the computer name but with a last byte of <20>); more variants of the domain name (<1B> and <1D> for browsing, and <1C>for the domain controllers); a replicator account; a Systems Management Server account; and so forth. The name registration request packet is 110 bytes. A positive name registration response is 104 bytes.
A name release request is sent for a name when its service stops, typically when the system shuts down. The name release request is 110 bytes and the name release response is 104 bytes.
A name refresh request (also called a renewal) is sent regularly while the name is registered. The request is 110 bytes, the response is 104 bytes. The time between renewals depends on the client implementation and the renewal interval. The implementation of WINS in Windows 2000 sends name refresh requests after half the renewal interval to the primary WINS server. When the primary goes down, the renewals are sent at the rate as specified by the renewal interval of the secondary. Only half the renewal attempts are actually done at the secondary; the other attempts are sent to the primary. If the WINS service at the primary WINS server is stopped, then the renewal attempt fails. However, the attempt still generates three packets.
Name query traffic depends on the application and the server. The application might disconnect from the server regularly to release the NetBIOS session. The file server might disconnect idle sessions. Different applications might connect to different servers. This all results in name query traffic; the name query request is 92 bytes, the response is 104 bytes.
Replication and verification traffic is slightly more complicated than typical network traffic because WINS servers perform replication and verification in batches to reduce traffic. In addition, replication and verification sometimes trigger challenge traffic when entries are verified at their owner.
Implementing replication and verification also requires the basic load of connecting and disconnecting with TCP. Each unique name entry requires WINS servers to exchange between 12 and 50 bytes; other types of name entries, such as a group name, which creates a load that depends on the number of clients in the group, might require servers to exchange more data. You can configure the replication interval to reduce the connection overhead, and configuring a persistent connection reduces the overhead to zero.
When planning for WINS client traffic on large routed networks, consider the effect of name query, registration, and response traffic routed between subnets. Name requests and responses that occur at the daily startup of computers must pass through the traffic queues on the routers and might cause delays at peak times.
You can estimate WINS client traffic based on the behavior of the WINS clients as described in the preceding sections. However, when estimating WINS client traffic, you must also consider the network topology and the design or configuration of the routers in the network—it might not be possible to predict the traffic load on a specific network router because the routers might be designed or configured to autonomously route traffic based on factors other than traffic load.