Network Infrastructure: Overview
As important as a solid network infrastructure is to users, it remains mostly unnoticed when it is functioning best, delivering reliable, secure, and fast connectivity. The user is most likely to interface directly with the network infrastructure through the following UIs, most of which will be available by Windows Vista® Beta 2.
Network Explorer and Network Map
As the replacement for My Network Places and Network Neighborhood, Network Explorer will serve as the hub for these scenarios and will enable users to quickly, easily and reliably find and interact with computers and devices on the local network or networks that the computer is connected to. From Network Explorer, users will be able to access the files, folders, and printers shared on computers on the local network. For network connected devices (NCDs), the Network Explorer will communicate installation status and expose a task for installing/uninstalling the devices.
The Network Map Control Panel provides a subset of the functionality of the Network Explorer. It supports the home and unmanaged network, providing the user with a simple way to:
View basic information about the device, including connection status
View how the devices on their network are connected together
Understand where issues are on their network
The following screenshot shows the Network Map in a home environment that currently has a broken connection to a wireless router.
The Network Explorer and Network Map use the Link Layer Topology Discovery (LLTD), Function Discovery (FD), and other communication protocols to discover networks, nodes and attached devices and then to enumerate their characteristics.
This Control Panel applet enables the user to view and manage their wired and wireless network infrastructure, as allowed by the administrative or domain policies currently in effect. The Network Center applet helps the user with the following tasks:
Connect to the Internet, local network, or an existing virtual private network (VPN)
Open the Sharing Center, which assists the user in sharing computer and peripheral resources
View computers and devices on the local network
Add a computer or a device to the network
Diagnose the currently used network and its recourses
The following screenshot shows the Network Center UI
Windows Security Center
This applet aggregates access to the configuration UI of the following four security capabilities: Windows Update, Internet Options, Windows Firewall, and Windows Defender (formerly known as Microsoft AntiSpyware).
The Windows Firewall configuration UI allows a user with administrative privileges to view and modify the settings of the Windows Firewall service.
Windows Firewall MMC Plug-in
A shortcut to this plug-in is located in the Administrative Tools folder and is named Windows Firewall with Advanced Security. This application allows the administrator to configure settings and filtering policies for the Windows Firewall service on the local computer.
Connect to a Projector Wizard
This special purpose application assists the user in connecting their computer to a network-connected projector. In contrast, locally connected projectors should be automatically detected when they are attached.
A great deal of design and development effort was focused on the networking subsystem in Windows Vista to improve its security, reliability and speed, while maintaining backward compatibility with most user-mode applications. The following diagram depicts the main components of this subsystem:
Although numerous improvements have been made throughout the networking subsystem, the following portions have been largely modified or are new:
The new Windows Vista network stack, dubbed the Next Generation Network Protocol Stack (NetIO), has been completely re-architected and re-implemented.
The new Http.sys kernel-mode and HttpApi.sys user-mode components provide streamlined access to HTTP transport services. Both the Windows HTTP Services (WinHTTP) API and Microsoft Internet Information Services (IIS) 7.0 are built on top of these components.
The Windows Filtering Platform (WFP) is a new component that represents a more reliable and easier-to-use alternative to the Winsock stack for network packet inspection, monitoring, and modification. WFP is the preferred approach for stack extensibility. It supersedes the Layered Service Provider (LSP).
The new Winsock Kernel (WSK) component provides kernel-mode developers a simpler development model to access network services. WSK is meant to largely replace TDI filters.
The Peer-to-Peer (P2P) Infrastructure has been improved. An adjunct P2P Collaboration API is provided.
Network Stack Improvements
The Windows networking stack was initially designed and developed in the early 1990s. Since then, it has evolved over the years to meet the changing and growing demands from the networking subsystem. However, nearly a decade after its design, the architectural and design limitations in its scalability and extensibility have become apparent. Windows Vista includes a completely new architecture for the network subsystem, including a new network stack. This Next Generation Network Protocol Stack (NetIO), diagramed below, includes completely rewritten TCP/IP and Web protocols. These improvements benefit existing applications through increased reliability, speed, resiliency, and security of the underlying network infrastructure. New applications can directly use some of the stack's new functionality through new Windows Vista Win32 APIs.
Winsock Stack Extensibility and Improvements
Winsock is a general-purpose stack-based architecture and an interface specification that is used to access and modify existing network services and create new network transport protocols. Winsock was developed by a consortium and is based on the socket interface in the Berkeley Software Distribution (BSD) standard. Winsock 2.0 is a WOSA-compliant standard that was introduced in 1993, and was included in Microsoft Windows 95. It retains its primary foundational role for user-mode network development in Windows Vista.
Winsock 1.x did not provide a mechanism for ISVs to provide a user-mode mechanism for extending the Winsock stack. In Winsock 2.x, the Layered Service Provider (LSP) was provided to insert custom code into the stack in a cooperative, layered manner. Unfortunately, third-party network extensions can cause instability in the network subsystem, especially when multiple LSPs are present. Windows Product Support Services (PSS) determined that approximately 12% of operating system failures are due to network stack extension (typically firewall or antivirus applications) incompatibility. Windows Vista seeks to minimize these instabilities by providing stable standardized interfaces for network extension developers, such as the Windows Filtering Platform (WFP). LSPs can only monitor network traffic that is routed through the Winsock stack. They cannot access data that flows through the new Http.sys component.
However, because special-purpose components might still require Winsock LSPs, the Windows Vista LSP architecture has been improved in the following ways:
A new categorization scheme based on behaviors has been added so that applications can conditionally include LSPs on a per-application basis.
System Critical Service (SCS) integrity has been improved by minimizing LSP dependencies. This feature uses the categorization scheme, such that only LSPs belonging to the categories the service permits are loaded for that service. By default, uncategorized LSPs are not included in an SCS.
In the future, the Microsoft Base Service Providers (BSPs) will no longer expose new extension functions through SIO_GET_EXTENSION_FUNCTION_POINTER. This was done to improve stability. Instead, provider-specific code should be exposed through the standard Winsock WSAIoctl function.
Many LSPs can be dynamically added/loaded without the need to restart. However, the user might still need to log out and log in.
A new install/uninstall API is introduced for LSPs. This API simplifies installation code and always leaves the Winsock catalog in a consistent state.
LSP and BSP installation and removal events are logged to the new Winsock catalog.
Better support is supplied to the ISV community through sample code (such as how to write non-Installable File System (IFS) LSPs), testing tools, and additional documentation.
For more information on the LSP architecture, see "Network Programming for Microsoft Windows, 2nd Edition" from the Microsoft Press (http://www.microsoft.com/learning/books) site.
The Winsock API is implemented as a user-mode API, which makes it impractical to use from kernel-mode applications, like device drivers. The new Winsock Kernel (WSK) API solves this problem by providing a kernel-mode, socket-based version of this API. Often WSK can be used as a more straightforward and reliable replacement for the traditional Transport Data Interface (TDI).
In addition to extensibility improvements, the Winsock Service Provider Interface (SPI) has been improved in Windows Vista with:
Support for IPv6 (carried on from Windows Server 2003) has been added in the form of new function calls and updated data structures. For more information, see "IPv6 Guide for Windows Sockets Applications" in the Windows SDK.
Support for 32-bit processes and catalogs on 64-bit platforms have been added. When new versions of functions are required to support this interoperation, those new versions have 32 appended to their names, as in WSCEnableNSProvider32. For more information, see "Winsock SPI Functions" in the Windows SDK.
The new functions WSASendMsg, WSAConnectByName, WSAConnectByList and WSAPoll have been added.
For more information about Winsock user-mode development, see "Windows Sockets 2" in the Windows SDK.
TCP/IP Stack Improvements
The TCP/IP stack in Windows Vista has been completely re-architected to be modular and extensible. It contains an integrated implementation of both IPv4 and IPv6 protocols, known as a dual Internet layer stack. This contrasts with the side-by-side stack implementation for these two protocols in Microsoft Windows XP. In addition, the new stack contains native support for IPSec and Windows sockets in kernel mode, and a new LSP model.
The full integration of IPv4 and IPv6 in the same TCP/IP stack assures a more consistent and efficient handling of these two protocols. IPv6 is the next generation IP protocol. Windows Vista will fully implement this standard, providing users, administrators, and developers the following advantages:
Broad, international acceptance — IPv6 is frequently an official government requirement, both in the United States and world-wide.
Superior packet structure — the IPv6 header minimizes overhead by introducing extension headers, which are separate from the main packet header. Extension headers are only present if a packet requires non-essential or optional fields. This structure does not affect routing performance because optional headers are not queried by routers.
Improved address management — in addition to increasing the absolute number of IP addresses possible by using 128-bit (16-byte) addresses, the IPv6 address space can easily be organized into multiple levels from the Internet backbone to the individual subnets within an organization. As a result, IT managers of domains working under IPv6 (such as a cluster of servers running Windows Server) are not forced to use Network Address Translation (NAT) to conserve addresses.
Efficient routing infrastructure and management — IPv6 addressing creates an efficient, hierarchical, and easily summarized routing infrastructure that is based on the common occurrence of multiple levels of Internet Service Providers (ISPs). In addition, the Neighbor Discovery (ND) protocol for IPv6 identifies a system's near neighbors and optimizes their interactions. (In this usage, ND replaces the IPv4 protocols ARP and ICMP.) Host configuration under IPv6 can be stateless, whereby hosts automatically configure themselves based on addresses of their near neighbors and prefixes advertised by local routers.
Built-in security and quality of service (QOS) — all networks and applications supporting IPv6 also support IPSec secure transmission. This means solution developers can now guarantee a consistent security standard. New fields in the IPv6 header define how traffic is handled and identified to support QOS schemes. QOS can be achieved even when the packet payload is encrypted through IPSec.
For most developers, the upgrade to IPv6 will not be noticeable; applications will continue to function as before. The one exception will be for developers using the Windows Sockets (Winsock) API. Additional support for IPv6 has been added, starting with Windows Server 2003. For more information about these extensions, see "IPv6 Guide for Windows Sockets Applications" in the Windows SDK.
In Windows Vista, the new IPSec driver has been closely integrated into the network stack, and further enhanced to provide the following features:
Support for new suites of authentication and encryption algorithms, such as Advanced Encryption Security (AES), ECP, Diffie-Helman, and Elliptic Curve Diffie-Helman (ECDH) key exchange.
A more complete IPSec security auditing that allows administrators to detect and diagnose problems, detect illegal activity, and manage network resources using performance counters. This feature uses the new Event Tracing for Windows (ETW) service to write event logs.
The IPSec kernel module includes Network Diagnostic Framework (NDF) helper classes that assist in the diagnosis, error reporting, and correction of problems associated with this network component.
Better integration within the Windows Filtering Platform (WFP), enabling access by third-party software such as firewalls. This integration enables application-level authorization, wherein authenticated and encrypted traffic can be filtered by application-based policies.
Better integration with Microsoft Active Directory domains so that either computer or user credentials can be used. IPSec is also used to enforce Network Access Protection (NAP) restrictions.
Designed to more efficiently allow specialized hardware processing (offloading), which is typically used in server configurations.
Because IPSec is provided at the IP layer, its services are available to the upper-layer protocols in the stack and, transparently, to existing applications.
Firewall and NAT Traversal
Increasingly, network security measures rely on network address translation (NAT) routers, and firewalls (such as the Windows Firewall). One downside to these measures is that they can interfere with communication between computers, especially in peer-to-peer (P2P) scenarios that span subnet boundaries. Windows Vista contains two technologies that can be configured to traverse these barriers by tunneling:
NAT traversal is supported through the Teredo service, which tunnels IPv6 using an IPv4-based UDP channel. For more information on Teredo, see "Teredo Overview" on the Microsoft TechNet (http://technet.microsoft.com) site.
Firewall traversal is supported through the Peer Name Resolution Protocol (PNRP) service and specially configured super-nodes. In this scheme, IPv6 packets are tunneled in an IPv4-based SLL channel.
A connection using Teredo is the preferred method; only if the client is behind a symmetric NAT router or a firewall will a Firewall traversal be attempted. The Windows Firewall has been designed to help secure the potential security opening created by these traversal methods.
Windows Vista and Microsoft Internet Explorer version 7 have extensive support built in for Really Simple Syndication (RSS), which allows users and applications to detect, subscribe to, preview, and download feed content.
Kernel-Mode and Hardware Improvements
The Windows Vista networking subsystem has been extensively modified to better support developers of device drivers and other kernel-mode components. Some of the more important changes include:
NDIS 6.0 is the next-generation network device interface for Windows Vista. It introduces a new way for developers to implement a new functionality within NDIS called Light Weight Filters. The NDIS 6.0 filter driver model reduces the complexity of code and increases performance.
The new Windows Filtering Platform (WFP) introduces new kernel-mode components, named callout modules that allow deep inspection and modification of network packets.
The new Winsock Kernel (WSK) API is easier to use than the Transport Data Interface (TDI) for developing kernel-mode networking components. The WSK provides semantics and structures that are familiar to developers experienced in writing socket code.
Winsock Direct (WSD) is a new API that enables Remote DMA (RDMA) kernel-bypass network communication to provide low-latency, low-CPU-usage data transfer.
Receive-Side Scaling allows multi-processor systems to process network traffic on all CPUs.
Network protocol offloading, which enables protocol processing in specialized hardware, is better supported. This feature results in increased network scalability, and is intended mainly for servers. Windows Vista natively supports offloading of the TCP, IPSec, and HTTP protocols.
For more information about kernel-mode network development, search for these topics in the Windows DDK documentation.
Performance and Quality of Service Improvements
The Windows Vista network subsystem contains a number of improvements that benefit performance and quality of service (QOS):
The network stack has been re-architected with an emphasis on stability and performance. Efficient modular design with minimal mode transitions along the processing path assure high throughput. IPv6, IPSec, and HTTP components have been better integrated into the stack, enabling much better throughput.
The network stack will supply more information (such as bandwidth usage, latency, diagnostics, and management metrics) to better enable applications to utilize the network.
Better overall reliability, diagnostics, and security guard against ill-behaving and malicious software (malware) components, which are a major source of network degradation.
The TCP/IP stack contains an auto-tuning mechanism that dynamically changes the advertised receive window based on the characteristics of the path over which the connection is made. Auto-tuning helps improve TCP throughput over high bandwidth-latency paths by not artificially limiting the throughput. With auto-tuning, network administrators no longer need to manually configure the TCPWindowSize registry key, although setting this key will disable auto-tuning.
NetIO has customized TCP congestion-control algorithms designed to supersede standard TCP protocols for high-speed networks. These advanced congestion-control algorithms will enable hosts to achieve high utilization on these multi-Gbps networks.
Windows Vista continues support for the industry standard Generic Quality of Service (gQOS) functions. To manage network performance of demanding applications like streaming media, Windows Vista contains additional QOS enhancements, such as a new implementation of the Network Location Awareness Service (NLA2) and the quality Windows Audio Video Experience (qWAVE).
Network Reliability, Security and Management Improvements
Windows Vista continues and extends Microsoft's focus on providing users with trustworthy computing, while maintaining ease-of-use. Windows Vista network applications will not only be more secure, they will provide users with enhanced throughput because of improved secure interface performance, and better control over how security is applied. As part of a layered approach to security, Windows Vista introduces the following network security features:
The network subsystem is hardened against common network attacks, such as all known penetration attacks, truncation and replay attacks, and security violations that occur in VPN/Terminal Services scenarios. Denial of Service attacks are ameliorated so that legitimate sessions can still be serviced.
IPSec and Secure Socket Layer (SSL) support has been integrated into the network stack to provide more reliable, faster, and more manageable secure communications.
The network subsystem contains a new isolation technology called routing compartments. This is a virtualization technology that allows secure and insecure networks to be isolated from each other when a host connects to multiple networks (at the same or different times).
Application support for the SSL – developers now have two high-level ways to programmatically access SSL:
Continued support of Microsoft Windows HTTP Services (WinHTTP), a server-supported interface to the HTTP/1.1 Internet protocol, including extensive support for SSL transactions. Windows Vista provides a slightly updated version of this API, WinHTTP version 5.1.
Managed applications using the .NET Framework 3.0 extensions can now provide SSL support through the SslStream and related classes in the System.Net.Security namespace.
When these applications are run on Windows Vista, they will automatically use the new kernel-mode support provided by Http.sys.
The Network Diagnostics Framework (NDF) is an extension of the Windows Diagnostics Infrastructure (WDI) that monitors the network subsystem. With NDF, ill-behaving network components can be automatically identified, diagnosed, reported, and often corrected.
The Windows Firewall has numerous improvements, including new outbound filtering, a new isolated Cocoon mode and IPv6 support, improved auditing and logging, and better integration with other network and security features.
The Windows Filtering Platform (WFP) is a new modular, more efficient architecture for interfacing with the TCP/IP stack. WFP introduces a new, straightforward development model for ISVs developing firewalls, new protocols, and stack inspection tools.
Network Access Protection (NAP) provides protected access to private networks. NAP provides an integrated detection of the state of a client attempting to connect to a network, restricting the access of the client until the policy requirements for connecting to the network have been met. NAP has an associated client and server API.
To combat more sophisticated Internet-based attacks and communication protocol exploits, an improved version of the Windows Firewall is included as a standard component of Windows Vista. New and improved features include:
Considerable improvements to its functionality, including outbound filtering (which can be centrally managed through Group Policy), IPv6 address support, negotiated discovery for IPSec connections, better service hardening, and a new Cocoon mode of operation. During Cocoon mode, the firewall will be turned on with no rule exceptions during high-risk activities (for example, while Windows Update is running).
The Windows Firewall API, a set of COM interfaces that were first introduced in Windows XP SP2, has been updated to support IPv6 addresses, Cocoon mode, and availability even when Windows Firewall is turned off (however, such omnipresent APIs only support ALLOW actions). For more information, see "Windows Firewall Interfaces" in the Windows SDK.
Incremental improvements in the UI to support new features like IPv6 and Cocoon mode.
Integration with other networking technologies to improve overall network functionality and security:
With NDF for easy firewall troubleshooting.
With WFP so that Windows Firewall works harmoniously with other network stack tools and extensions. WFP notifies other applications of network traffic changes initiated by Windows Firewall.
With firewall and NAT traversal so that Windows Firewall will continue to protect computers from attack even though a bidirectional hole (direct tap) is created through the edge firewall.
With User Account Control (UAC), to limit access to the Firewall Control Panel applet and sensitive query dialogs to users with administrative privileges.
Windows Filtering Platform (WFP)
WFP is a new architecture in the TCP/IP stack of Windows Vista that allows unprecedented access to the TCP/IP packet processing path. Outgoing and incoming packets can be examined, modified, or even blocked from further processing. WFP is not a firewall. It is a set of system services and APIs that enable ISVs to create firewalls, anti-virus software, diagnostic software, encryption and verification services, and other types of applications, tools, and services. For example, the Windows Vista Personal Firewall – the successor to the Internet Connection Firewall in Windows XP before Service Pack 2 (SP2) and the Windows Firewall in Windows XP SP2 and later – will be built using WFP.
WFP provides Win32 APIs so that third-party applications can participate in the filtering decisions that take place at several layers in the TCP/IP protocol stack and throughout the operating system. WFP also integrates and provides support for next-generation firewall features, such as authenticated communication and dynamic firewall configuration based on an application's use of the Windows Sockets API (application-based policy).
Compared to alternate techniques, applications built with WFP will be more reliable, efficient, and flexible, with less development cost. Specific beneficial features of WFP include:
Provides applications a fine level of access control to the various layers of the TCP/IP packet processing path.
Because WFP already contains a filtering engine and provides programmatic access to it, applications do not have to build custom filtering logic.
In previous versions of Windows, existing hooks into the TCP/IP packet processing path were not supported, and were subject to change. WFP is a standard API supported by Microsoft.
Applications that use WFP will be more reliable than alternative mechanisms, and less subject to breaking when Windows Vista service packs are released or other stack-based software is installed.
The WFP architecture is logically segmented into kernel-mode and user-mode components, with the WFP API residing in user mode. This enables many filtering applications to run entirely in user mode, isolating the system so that a component failure does not destabilize the entire Windows operating system.
Because all the applications and services use the same filtering engine, it is easier to determine whether there are other applications or services present and what their functions are.
Third-party developers will generally build two types of applications upon the WFP platform:
User-mode components that strictly use the WFP API to set filters at the different layers in the TCP/IP stack.
Mixed-mode or kernel-mode components that perform deeper analysis through callout drivers, which are registered through the WFP API to intercept relevant packets for inspection or modification.
Windows Vista still supports the Windows Firewall APIs introduced in Windows XP SP2. The WFP API is convenient for applications that have modest needs to create, enable, and disable firewall exceptions. For example, an application might need to enable traffic through selected ports. This API is available even if the firewall is currently disabled, because requests are actually handled by WFP.
It is expected that the availability of WFP will reduce the need for custom NDIS drivers and Winsock Layered Service Provider (LSP) modules.
Client-Side Network Programming Improvements
Windows Vista continues its support for low-level client-side network development through the existing WinINet and WinHTTP Win32 APIs and .NET Framework 3.0. All of these APIs have been substantially updated through bug fixes and additional functionality.
Many solution developers, especially at the enterprise level, will want to communicate at a higher level, probably through the HTTP protocol. For more information on Microsoft solutions in this area, see Connecting Technologies.
Windows Internet (WinINet) API
WinINet is Microsoft's original API for client-side Internet protocol communication, such as FTP and HTTP. Although it is natively available only as a Win32 C-level interface, the Microsoft Foundation Class (MFC) Library encapsulates much of this functionality in a set of C++ classes. The following main improvements have been introduced for WinINet in Windows Vista:
Support has been added for IPv6 literals in all supported protocols, such as addresses for HTTP, FTP, and SDP protocols. This change should be largely transparent to developers not directly manipulating these literals.
Full support for IDN and Unicode strings has been added. Unicode literals are uniformly converted to ACE (ASCII Compatible Encoding) "Punycode" (as defined by RFC 3492) strings. Two new functions, IDNToASCII and IDNToUnicode, give developers access to IDN string conversion capabilities.
Decompression support has been added for the gzip and deflate content encodings. This change simplifies development by unburdening the application of this task. Also, it improves the WinINet caching mechanism to RFC 2616 compliance with respect to proper handling of the Cache-Control and Content-Encoding response headers, as well as the proper handling of Accept-Encoding request headers. Decompression is controlled through the new INTERNET_OPTION_HTTP_DECODING value (for example, by passing this value to the InternetSetOption function).
For more information about WinINet, see "Windows Internet" in the Windows SDK. For more information about MFC WinINet classes, see "Win32 Internet Extensions (WinINet)" in the MSDN Library (http://msdn.microsoft.com).
Windows HTTP Services (WinHTTP) API
WinHTTP provides developers with an HTTP client API to send requests through the HTTP protocol to other HTTP servers. It differs from WinINet in two main ways. It is limited to the HTTP protocol, and it properly handles impersonation required by services fulfilling user requests.
Minor improvements have been made to the WinHTTP API version 5.1 that was first delivered for Windows Server 2003, including:
Support for IPv6 literals and IDN names.
The WinHttpSetOption function has additional options for setting the response timeout, the maximum number of automatic redirects, the maximum number of ignored informational status code responses, the maximum response header size, and the maximum amount of data drained from responses in order to reuse a connection.
Proxies are not trusted when the auto-logon security level is set to high (when the WINHTTP_AUTOLOGON_SECURITY_LEVEL_HIGH policy option is set).
To ease the configuration of proxy settings for WinHTTP-based applications, the new Web Proxy Auto-Discovery (WPAD) protocol (autoproxy) is implemented.
WinHTTP is further improved through the following changes:
Support for very large data uploads (up to 2^64 bytes in length) – the Content-Length header during a WinHttpSendRequest call overrides the value of the DWORD dwTotalLength parameter of this function.
Support for chunked data transfer encoding through the WinHttpWriteData function – the Transfer-Encoding header during a WinHttpSendRequest call. If the request specifies a non-identity header, then the dwTotalLength parameter of the WinHttpSendRequest function is overridden.
Improved security support, including support for issuer list retrieval for SSL client authentication and optional client certification requests. In the latter, the application can supply a NULL client certificate to communicate to the server that it does not have a client certificate for SSL authentication.
Support for source port range reservation – an application can supply a TCP port reservation token that is associated with sockets that subsequently connect to service the request. This effectively enables applications to control the source port from which an HTTP request is to be sent out.
Netsh extensions for WinHttp proxy configuration and trace configuration to replace the Proxycfg.exe and Winhttptraceconfig.exe command-line tools.
For more information, see "Windows HTTP Services (WinHTTP)" in the Windows SDK.
.NET Framework 3.0 Network Classes
The .NET Framework 2.0 includes extensive support for low-level client network development in the System.Net namespace and its child namespaces, five of which are new.
.NET Framework 3.0 Namespace
Provides a simple API for many of the protocols used on networks today.
New. Defines the types and enumerations used to define cache policies for resources obtained using pluggable protocol classes.
New. Enables the access and update of configuration settings for the System.Net namespaces.
New. Provides support for sending electronic mail through a Simple Mail Transfer Protocol (SMTP) server.
New. Defines types that represent the Multipurpose Internet Mail Exchange (MIME) headers used in SMTP mail and other Internet applications.
New. Provides access to network traffic data, network address information, notification of address changes for the local computer, and an implementation of the Ping tool.
Supplements the System.Net.Sockets namespace to provide secure streams for communications between nodes.
Provides a sockets-based interface (that encapsulates the WinSock API) for developers who need to tightly control access to the network.
Even within the two existing namespaces, there are a number of new classes that add interesting functionality, for example:
HTTPListener and related classes support the creation of a simple HTTP protocol listener that responds to HTTP requests.
FTP client functionality has been encapsulated by the new classes FtpWebRequest and FtpWebResponse.
New classes to represent the following events:
Downloads - DownloadDataCompletedHandler, DownloadProgressChangedHandler, and DownloadStringCompletedHandler.
Uploads - UploadDataCompletedEventHandler, UploadFileCompletedEventHandler, UploadProgressChangedEventHandler, UploadStringCompletedEventHandler, and UploadValuesCompletedEventHandler.
Web client and server I/O completion - OpenReadCompletedEventHandler and OpenWriteCompletedEventHandler.
Full documentation for the network namespaces can be found in the MSDN Library (http://msdn.microsoft.com).
Discontinued and Deprecated Network Features
In conjunction with re-architecting the network stack, support has either been discontinued or deprecated for some protocols and features. Deprecated features are carried forward for backward compatibility, but are not improved and will probably be discontinued in a future version of Windows. Discontinued features are no longer supported by Microsoft.
NetDDE Is Discontinued
This network protocol is an extension of the Dynamic Data Exchange (DDE) protocol for inter-process communication (IPC). It has been superseded by newer, network-aware IPC mechanisms such as RPC, WinSockets, DCOM, .NET Framework remoting, and Web services. For more information, see Connecting Technologies.
NetBIOS, NetBEUI, and NBT Are Deprecated
These early network services were a standard for early proprietary local computer networks. As such, NetBIOS has inherent limitations and has been superseded by open Internet standards based on TCP/IP, DNS, and DHCP.
Transport Data Interface (TDI) Is Deprecated
This interface for creating kernel-mode network extensions has been superseded in Windows Vista by the WinSock Kernel (WSK) and Windows Filtering Platform (WFP) APIs. WFP also enables user-mode network extensions. TDI Clients and Filter Drivers will be supported but will incur a performance penalty.
Network Stack Hooking Is Discontinued
Network component custom interjection of code into the network stack, which was necessary for the development of some network applications in previous versions of Windows, will no longer function in Windows Vista because of the new protected architecture of the network subsystem. Instead, use WFP or Winsock Layered Service Providers (LSPs).
Gopher Protocol Is Deprecated
This older protocol is disabled by default but can be reactivated through a registry change.