The net use command is an example of a connection-oriented communication, as illustrated in Figure 13.5.
Figure 13.5 Connection-oriented Network Traffic
When a user types net use at the command line to connect to a shared resource, NBF must first locate the server by sending UI-frames, and then initialize the link. This is handled by the redirector when it makes a connection to the NBF drivers by using the TDI interface. NBF begins the sequence by generating a NetBIOS Find Name frame. Once the server is found, a session is set up with Class-II frames which contain timing parameters following the 802.2 protocol standard (802.2 governs the overall flow of data).
The client computer sends a Set Asynchronous Balance Mode Extended (SABME) frame, and the server returns an Unnumbered Acknowledgment (UA) frame. Then the client sends a Receive Ready (RR) frame, notifying the server that it is ready to receive Informational (I) frames whose sequence number is currently 0. The server acknowledges this frame.
Once the LLC-level session is established, additional NetBEUI-level information is exchanged. The client sends a Session Initialize frame, and then the server responds with a Session Confirm frame. At this point, the NetBEUI-level session is ready to handle application-level frames (Server Message Blocks, or SMBs).
Reliable transfer is achieved with link-oriented frames by numbering the I-frames. This allows the receiving computer to determine whether the frames were lost and in what order they were received.
NBF improves performance for connection-oriented traffic through two techniques: use of adaptive sliding windows and use of link timers. The next two sections describe these techniques.
NBF uses an adaptive sliding window algorithm to improve performance while reducing network congestion and providing flow control. A sliding window algorithm allows the Windows NT-based computer using NBF to dynamically tune the number of LLC frames sent before an acknowledgment is requested. Figure 13.6 shows frames traveling through a two-way pipe.
Figure 13.6 Adaptive Sliding Window
If the sending computer could send only one frame on to the network and then had to wait for an acknowledgment (ACK), the sending computer would be underused. The frames would travel forward, and then ACKs for the received frames would have to travel back to the sending computer before it could send another frame. The number of frames that the sender is allowed to send before it must wait for an ACK is referred to as the send window.
The number of frames that a receiving computer is allowed to receive before sending an ACK to the sending computer is referred to as a receive window. In general, NBF has no receive window, unless it detects that the remote sending computer is running a version of IBM NetBEUI which does not support polling; in this case, NBF uses a receive window based on the value of MaximumIncomingFrames in the Registry.
The default value for MaximumIncomingFrames is 2 and this value does not dynamically change. It must be manually changed by using the Registry Editor. For additional information about the receive window, refer to "Using Windows NT NetBEUI in IBM LAN Server Networks" in the section "Troubleshooting NetBEUI" later in this chapter.
The adaptive sliding window protocol tries to determine the best sizes for the send window based on current network conditions. Ideally, the windows should be big enough so that maximum throughput can be realized. However, if the window gets too big, the receiving computer could get overloaded and drop frames.
Dropped frames cause significant network traffic because more frames have to be retransmitted. Dropped frames might be a problem on slow links or when frames have to pass over multiple hops to find the destination computer. Dropped frames coupled with large send windows generate multiple retransmissions. This traffic overhead might make an already congested network worse. Limiting the send window size can improve performance by reducing network traffic.
NBF uses three timers to help regulate network traffic: the response timer (T1), the acknowledgment timer (T2), and the inactivity timer (Ti). These timers are controlled by the values of the Registry parameters DefaultT1Timeout, DefaultT2Timeout, and DefaultTiTimeout, respectively.
The response timer is used to determine how long the sender should wait before it assumes that the I-frame is lost. After T1 milliseconds, NBF sends an RR frame and doubles the value for T1. If the RR frame is not acknowledged after the number of retries defined by the value of LLCRetries, the link is dropped.
Where the return traffic does not allow the receiver to send an I-frame within a legitimate time period, the acknowledgment timer begins, and then the ACK is sent. The value for this timer is set by the T2 variable, with a default value of 150 milliseconds. If the sender has to wait until the T2 timer starts in order to receive
a response, the link might be underused while the sender waits for the ACK. This rare situation can occur over slow links. On the other hand, if the timer value is too low, the timer starts and sends unnecessary ACKs, generating excess traffic. NBF is optimized so that the last frame that the sender wants to send is sent with the POLL bit turned on. This forces the receiver to send an ACK immediately.
The inactivity timer, Ti, is used to detect whether the link has gone down. The default value for Ti is 30 seconds. If Ti milliseconds pass without activity on the link, NBF sends an I-frame for polling. This is then ACKed, and the link is maintained.
Note
Remember that T2 is less than or equal to T1, which is less than or equal to Ti.
The T1 parameter is tuned dynamically on a per-link basis, based on link conditions and throughput. The value of the T1 parameter as specified in the Registry is used as the starting value for how long the process should wait for a response. This registry parameter can be changed. For example, if you know that the computer connects to the network on a slow link, the T1 registry parameter value can be increased. However, even if this parameter is not changed, NBF can detect the slow link quickly and automatically tune the T1 registry parameter value.
T2 and Ti are not adapted dynamically.