Operating System Microsoft Windows 2000 tcp/ip implementation Details
Download 0.63 Mb.
|
- Navigate this page:
- Transport Driver Interface (TDI)
- Network Application Interfaces
- Name and Address Resolution
- Support for IP Multicasting
User Datagram Protocol (UDP)UDP provides a connectionless, unreliable transport service. It is often used for too many communications that use broadcast or multicast IP datagrams. Since delivery of UDP datagrams is not guaranteed, applications using UDP must supply their own mechanisms for reliability, if needed. Microsoft networking uses UDP for logon, browsing, and name resolution. UDP can also be used to carry IP multicast streams. UDP and Name ResolutionUDP is used for NetBIOS name resolution by unicast to a NetBIOS name server or subnet broadcasts, and for DNS host name to IP address resolution. NetBIOS name resolution is accomplished over UDP port 137. DNS queries use UDP port 53. Because UDP itself does not guarantee delivery of datagrams, both of these services use their own retransmission schemes if they receive no answer to queries. Broadcast UDP datagrams are not usually forwarded over IP routers, so NetBIOS name resolution in a routed environment requires a name server of some type, or the use of static database files. Mailslots over UDPMany NetBIOS applications use mailslot messaging. A second-class mailslot is a simple mechanism for sending a message from one NetBIOS name to another over UDP. Mailslot messages can be broadcast on a subnet or directed to the remote host. To direct a mailslot message to another host, there must be some method of NetBIOS name resolution available. Microsoft provides Windows Internet Name Server (WINS) for this purpose. NetBIOS over TCP/IPThe Windows NT and Windows 2000 implementation of NetBIOS over TCP/IP is referred to as NetBT. NetBT uses the following TCP and UDP ports:
NetBIOS over TCP/IP is specified by RFC 1001 and RFC 1002. The NetBT.sys driver is a kernel-mode component that supports the Transport Driver Interface (TDI) interface. Services such as Workstation and Server use the TDI interface directly, but traditional NetBIOS applications have their calls mapped to TDI calls by the Netbios.sys driver. Using TDI to make calls to NetBT is a more difficult programming task, but can provide higher performance and freedom from historical NetBIOS limitations. NetBIOS concepts are discussed further in the “Network Application Interfaces” section of this document. Transport Driver Interface (TDI)Microsoft developed the Transport Driver Interface (TDI) to provide greater flexibility and functionality than is provided by existing interfaces, such as NetBIOS and Windows Sockets. All Windows transport providers expose TDI. The TDI specification describes the set of primitive functions by which transport drivers and TDI clients communicate and the call mechanisms used for accessing them. Currently, TDI is kernel-mode only. The Windows 2000 redirector and server both use TDI directly, rather than going through the NetBIOS mapping layer. By doing so, they are not subject to many of the restrictions imposed by NetBIOS, such as the legacy 254-session limit. TDI FeaturesTDI may be the most difficult to use of all Windows network APIs. It is a simple conduit, so the programmer must determine the format and meaning of messages. TDI includes the following features:
More information on TDI is available from the Windows 2000 Device Driver Kit (DDK). Security ConsiderationsNetwork security is a serious consideration for administrators with machines exposed to public networks. Microsoft’s TCP/IP stack has been hardened against many attacks and in its default state handles most of the common attacks. Some additional protection against popular Denial of Service attacks can be added by enabling the SynAttackProtect key in the registry. This key allows the administrator to choose several levels of protection against SYN attacks. Here are general guidelines that can lower your vulnerability to attack:
Consult the Microsoft Security Web site regularly for security bulletins. The Windows Sockets interface is currently popular. A quick overview of the Windows Sockets Interface and the NetBIOS Interface is presented here. Windows SocketsWindows Sockets specifies a programming interface based on the familiar socket interface from the University of California at Berkeley. It includes a set of extensions designed to take advantage of the message-driven nature of Microsoft Windows. Version 1.1 of the specification was released in January 1993, and version 2.2.0 was published in May of 1996.8 Windows 2000 supports version 2.2, commonly referred to as Winsock2. ApplicationsThere are many Windows Sockets applications available. A number of the utilities that ship with Windows 2000 are based on Windows Sockets, including the FTP and DHCP clients and servers, Telnet client, and so on. There are also higher-level programming interfaces that rely on Winsock, such as the Windows Internet API (WinInet) used by Internet Explorer. Name and Address ResolutionWindows Sockets applications generally use the gethostbyname() function to resolve a host name to an IP address. The gethostbyname() function uses the following (default) name look-up sequence:
Some applications use the gethostbyaddr() function to resolve an IP address to a host name. The gethostbyaddr() call uses the following (default) sequence:
Support for IP MulticastingWinsock2 provides support for IP multicasting. Multicasting is described in the Windows Sockets 2.0 specification and in the IGMP section of this document. IP multicasting is currently supported only on AF_INET sockets of the types SOCK_DGRAM and SOCK_RAW. Backlog ParameterWindows Sockets server applications generally create a socket, and then use the listen() function on it to listen for connection requests. One of the parameters passed when calling listen() is the backlog of connection requests that the application would like Windows Sockets to queue for it. This value controls the number of unaccepted connections that can be queued. Once an application accepts a connection, it is moved out of the connection request backlog and no longer counts. The Windows Sockets 1.1 specification indicates that the maximum allowable value for a backlog is 5; however, Windows NT 3.51 accepts a backlog of up to 100, Windows NT 4.0 and Windows 2000 Server accept a backlog of 200, and Windows NT 4.0 Workstation and Windows 2000 Professional accept a backlog of 5 (which reduces memory demands). Push Bit InterpretationBy default, Windows 2000 TCP/IP completes a recv() call when one of the following conditions is met:
If a client application is run on a computer with a TCP/IP implementation that does not set the push bit on send operations, response delays may result. It is best to correct this on the client; however, a configuration parameter (IgnorePushBitOnReceives) was added to Afd.sys to force it to treat all arriving packets as though the push bit were set. This parameter was new in Windows NT 4.0 and is supported in Windows 2000. Directory: pub -> doc doc -> Assembly language/machine language/coding tutorial part one by scatt index prefix part one : The Basics An Introduction. First Steps Processors Bits and Bytes doc -> English words and phrases doc -> Notices regarding the use of these documents doc -> Gsg-linux-vt 01 doc -> In Proceedings of 15 th doc -> Performance Modeling of Parallel and Distributed Computing Using pace doc -> A dragon in the tube doc -> Revisão Bibliográfica: Learning Vector Quantization 28/04/2003 doc -> Revisão bibliográfica redes neurais recorrentes doc -> Revisão Bibliográfica: Autômatos Celulares Download 0.63 Mb. Share with your friends:
|