Windows Core Networking : System.Net

Creating IP Agnostic Applications - Part 2 (Dual Mode Sockets)

wndpteam — Tue, 24 Oct 2006 20:59:00 GMT

In a previous post I wrote about how on Windows Vista and Windows Server "Longhorn," IPv6 is installed and enabled by default and that when both IPv4 and IPv6 are enabled, the TCP/IP stack prefers to use IPv6 over IPv4. With the growth of IPv6, applications must now work seamlessly over both protocols (IPv4 & IPv6). The remainder of this post discusses one way to make handling both protocols easier by using a single socket that works with IPv4 & IPv6. No longer do you need to create two sockets to make your application IPv4 & IPv6 aware :).

Windows Vista and Windows Server Longhorn includes a new TCP/IP stack which includes common TCP & UDP layers on top of the IPv4 and IPv6 layers. This new architecture has made it possible for a single IPv6 socket to work with both IPv6 and IPv4. For example, using a single IPv6 socket one can now accept BOTH IPv4 and IPv6 traffic. Such a socket is typically dubbed a "dual mode" socket. Dual mode sockets are usable by managed code sockets (ie. System.Net.Sockets.Socket), native Winsock sockets as well as Winsock Kernel (WSK) sockets.

To create a "dual mode" socket, the following steps are needed:

Create an IPv6 socket
Set the IPV6_V6ONLY socket option to false

Once you have created the socket and set the appropriate option, the socket can be used to accept incoming IPv4/v6 connections or connect to an IPv4/v6 destination. The snippets below outline accepting incoming connections over both protocols in native and managed code:

Note: The code is meant as demonstration code; error code checking and exception handling have been left off the code snippets to keep them as concise as possible.

.NET (C#)

Socket sock = new Socket(AddressFamily.InterNetworkV6, SocketType.Stream, ProtocolType.Tcp);
// 27 is equivalent to IPV6_V6ONLY socket option in the winsock snippet below
sock.SetSocketOption(SocketOptionLevel.IPv6, (SocketOptionName)27, 0);
sock.Bind(new IPEndPoint(IPAddress.IPv6Any, 8000));
sock.Listen(5);
Socket client = sock.Accept();
// send / receive data on 'client' socket

Winsock

WSADATA wsaData;
SOCKET lsock = INVALID_SOCKET;
SOCKET csock = INVALID_SOCKET;
SOCKADDR_STORAGE serverAddr = {0};
SOCKADDR_STORAGE clientAddr = {0};
int off = 0;
int port = 8000;
int clientAddrLen = sizeof(clientAddr);
WSAStartup(MAKEWORD(2,2), &wsaData); 
serverAddr.ss_family = AF_INET6;
INETADDR_SETANY((SOCKADDR *)&serverAddr);
SS_PORT(&serverAddr) = htons(port);
lsock = socket(AF_INET6, SOCK_STREAM, IPPROTO_TCP)

//make the socket a dual mode socket
setsockopt(lsock,IPPROTO_IPV6,IPV6_V6ONLY,(char *)&off, sizeof(off));
bind(lsock, (SOCKADDR *)&serverAddr, (int)INET_SOCKADDR_LENGTH(serverAddr.ss_family));
listen(lsock, 5);
csock = accept(lsock, (SOCKADDR *)&clientAddr, &clientAddrLen); 
... 
... 
WSACleanup();

When using a dual mode socket, it is important to remember the socket is at root an IPv6 socket. Since this is the case, when specifying an IPv4 address to such a socket (ie. connect to IPv4 endpoint using a dual mode socket) one must format the IPv4 address as an IPv4 mapped address prior to passing the address to a socket function. Fortunately, one can use IN6ADDR_SETV4MAPPED(...), defined in mstcpip.h to simplify this task.

The following shows an example of what this looks like in Winsock:

WSADATA wsaData;
SOCKET csock = INVALID_SOCKET;
SOCKADDR_STORAGE addrLoopback4 = {0}; 
int port = 8000;
int off = 0; 
addrLoopback4.ss_family = AF_INET;
INETADDR_SETLOOPBACK((SOCKADDR*)&addrLoopback4);
SS_PORT(&addrLoopback4) = htons(port); 
WSAStartup(MAKEWORD(2,2), &wsaData);
if((csock = socket(AF_INET6, SOCK_STREAM, IPPROTO_TCP)) == INVALID_SOCKET)
{
     //error creating the listening socket
     WSACleanup();
     return 1;
} 
//make the socket a dual mode socket
setsockopt(csock,IPPROTO_IPV6,IPV6_V6ONLY,(char *)&off, sizeof(off)); 
// format the address as a v4 mapped address if needed
ConvertToV4MappedAddressIfNeeded((SOCKADDR *) &addrLoopback4);
// connect
connect(csock, (SOCKADDR *)&addrLoopback4, sizeof(addrLoopback4)); 
printf("Connect complete"); 
closesocket(csock); 
WSACleanup();
return 0; 
  


void ConvertToV4MappedAddressIfNeeded(PSOCKADDR pAddr)
{
    // if v4 address, convert to v4 mapped v6 address
    if (AF_INET == pAddr->sa_family)
    {
        IN_ADDR In4addr;    
        SCOPE_ID scope = INETADDR_SCOPE_ID(pAddr);
        USHORT port = INETADDR_PORT(pAddr);
        In4addr = *(IN_ADDR*)INETADDR_ADDRESS(pAddr);
        ZeroMemory(pAddr, sizeof(SOCKADDR_STORAGE));
        IN6ADDR_SETV4MAPPED(
             (PSOCKADDR_IN6)pAddr,
             &In4addr,
             scope,
             port
             ); 
    }
}

Cheers,

-- Mike Flasko

Creating IP Agnostic Applications - Part 1

wndpteam — Tue, 29 Aug 2006 18:00:00 GMT

In Windows Vista and Windows Server "Longhorn," IPv6 is installed and enabled by default. When both IPv4 and IPv6 are enabled on these OSs, the TCP/IP stack prefers to use IPv6 over IPv4. For example, APIs such as ConnectByName will attempt to connect first via IPv6. See this post for a detailed discussion of address sorting.

Since the IPv6 stack has been enhanced, is installed by default and the preferred network layer, it is important when writing network code to ensure your application is IP agnostic. That is, your application should be able to function well when:

IPv4 and IPv6 are installed
IPv4 is the only network layer protocol installed
IPv6 is the only network layer protocol installed

At first glance this requirement may seem like significant added complexity for an application developer, but there is good news :). We have been actively working on ways to make writing IP agnostic applications simple. The remainder of this post will talk about how to get started making your apps IPv6 aware. In a subsequent post, I hope to drill down into specific topics.

Check Out the Porting Guide

When writing such applications, I suggest reading the Winsock IPv6 Porting Guide. This document is applicable to Windows Vista and Windows Server Longhorn as well as many prior OSs such as Windows XP and Window Server 2003. While the document speaks directly to the use of native code Winsock APIs, the concepts presented are directly applicable to both native and managed code (ie. .Net Framework). Would a version of this document targeted at managed code development be useful? Are there areas of the porting guide you would like expanded? If so, please let us know.

How to Check if IPv4 or IPv6 is Installed

One of the first tasks you may need to do is determine if IPv4 and/or IPv6 are installed on the machine. I believe there a number of suggested methods out there, but the recommended method which will reliably tell you if a protocol is installed is to attempt to create a socket for the address family in question.

For Winsock developers, this is accomplished by calling the socket or WSASocket function with the address family parameter set to AF_INET to test IPv4 availability and AF_INET6 for IPv6.

For .Net Framework applications, use the Socket.SupportsIPv4 property to test IPv4 availability and Socket.OSSupportsIPv6 for IPv6.

Note: There is a Socket.SupportsIPv6 property, but this is NOT the one you want in this case. For compat reasons we could not change the meaning of this property which does not tell you whether the machine has IPv6 installed, but instead gives back the value of a legacy configuration switch.

Previous Posts

Brad Williamson has posted already on a couple of the APIs available on Windows Vista & Windows Server "Longhorn" which simplify connection establishment for IP agnostic apps.

-Mike Flasko

Recent System.Net Related Postings

wndpteam — Tue, 18 Jul 2006 08:41:00 GMT

Recently, a number of current and former System.Net team members have posted about various managed code network programming topics:

Proxy configuration with HttpWebRequest

Socket programming considerations

HttpWebRequst & Pipelining

Know of other System.Net related blogs? If so, we eagerly await the URL(leave a comment with the URL)

-Mike Flasko

Simple .NET TCP Framing Example

wndpteam — Fri, 07 Apr 2006 01:45:00 GMT

Recently, Jon Cole from the System.Net QA team posted a great article in response to questions we've received on our .Net Networking Forum (http://forums.microsoft.com/MSDN/ShowForum.aspx?ForumID=40&SiteID=1). His post can be found here: http://blogs.msdn.com/joncole/archive/2006/03/20/555721.aspx

Excerpt from the article:

A common misunderstanding for developers new to network programming over TCP sockets is how messages are sent and received. I frequently hear the statement that "my data is not arriving on the other side of the socket in the same format that I sent it." The most common cause of this is because the TCP protocol does not guarantee that it will keep message boundaries. In other words, you could send "Hello World" in a single call to Send(), but the other side of the socket stream may have to do multiple Receive() calls on the socket to get all of the data (the first Receive might return "he" and the second "llo world"). ........

-- Mike Flasko

.Net Framework 2.0 - What's new

wndpteam — Wed, 02 Nov 2005 06:53:00 GMT

On October 27th the .Net Framework 2.0 was made available to MSDN subscribers and launch events will be start in early November. To see an overview of whats new in the .Net Framework and the System.Net name space please see:

http://msdn2.microsoft.com/en-us/library/t357fb32

Mike Flasko
Program Manager - WNDP

System .NET features and future

wndpteam — Tue, 06 Sep 2005 19:43:00 GMT

As many of you may already know, the release of Visual Studio .NET 2005 is right around the corner… hooray! As we put the final touches on “Whidbey” for the November 7th launch we are starting a parallel effort focused on planning for our next major release of Visual Studio, codenamed “Orcas”.

As we switch hats from ”Whidbey” release to “Orcas” planning, the System.Net team would like to hear directly from networking application developers on what they would like to see from System.Net in the future.

Some questions that we have been asking ourselves that you may also want to consider …

What features would you like to see enhanced in the System.Net namespace?
What functionality would you like to see from the Visual Studio .Net IDE as it relates to creating rich networking applications?
Do you find yourself always writing the same lines of code to accomplish a networking-related task that we should consider simplifying? An example of this is the work that we did with the WebClient class that allows applications to easily send/receive data to an URI with just a few lines of code.
Is there anything that you believe we have missed the mark on with System .Net?
Have you went down the path designing and/or developing an application with System .Net that you later could not finish due to a limitation with the classes?
Are there features in other platforms that you would to see in System.Net?
How would you rate the overall experience of creating network applications in .Net?
Are you using the HttpListener classes? And if so, what type of functionality would you like to see added?
Are there any HTTP-based protocols that you would like see added or expanded-on in the System.Net classes?

Beyond the features and functionality of the classes, we also would like to learn about network applications, past, present and future that are being built by .NET developers! So please let us know about the applications that you have created or are in the process of creating by replying to this post in the .NET Framework and Communication forum, as a comment to this post on our WNDP team blog, or simply by sending the System.NET team an email.

The System.Net classes are about enabling developers to write robust, secure networking applications for the client and the server. And as we begin planning for the future of the networking classes we want to be sure that we hear about what you would like to see. We look forward to hearing from you.

Thanks!

Billy Anders
Group Program Manager
Windows Networking Developer Platform
billy.anders@microsoft.com
http://blogs.msdn.com/wndp/

This has been cross-posted on the WNDP blog and the System .Net forum.

Automatic Proxy Configuration in System.NET

wndpteam — Wed, 03 Aug 2005 08:28:00 GMT

MSDN Magazine recently published a great read on changes to web proxy functionality in the .NET Framework 2.0. In the article, Take the Burden Off Users with Automatic Configuration in .NET, fellow WNDP team member and test lead for the managed network programming APIs (aka System.NET), Durgaprasad Gorti, gives new details about changes to web proxy support in System.NET such as how the System.NET classes now honor the automatic proxy configuration settings as used by Internet Explorer and connection-specific proxy settings.

In his article, Durgaprasad also provides sample code that demonstrates the new functionality and gives a short introduction to the Web Proxy Auto-Discovery Protocol as well.

MSDN Magazine on Winsock/System.Net

wndpteam — Wed, 20 Jul 2005 05:29:00 GMT

MSDN Magazine for August 2005 has an article about System.Net.Sockets and WinSock by Daryn Kiely:

Sockets are the transport mechanism most frequently used in high-performance server applications. Fortunately, the Win32^® Windows^® Sockets library (Winsock) provides mechanisms to improve the performance of programs that use sockets, and the Microsoft^® .NET Framework provides a layer over Winsock so that managed applications can communicate over sockets. So much advanced socket support is great, but using all these layers to write a truly high-performance socket-based application requires a little background information.

I am going to write a trivial chat server app to explore methods for writing a socket-based server and client using the base System.Net.Sockets.Socket class. Although .NET provides higher-level abstractions like the TcpListener and TcpClient classes (also in System.Net.Sockets), these classes are missing some of the advanced features exposed by the lower-level Socket class. That said, they can be useful in many situations. The TcpListener class provides simple methods that listen for and accept incoming connection requests in blocking synchronous mode, while the TcpClient class provides simple methods for connecting, sending, and receiving stream data over a network in synchronous blocking mode.

-- Ari Pernick (arip)

Run ASMX without IIS

wndpteam — Thu, 23 Jun 2005 11:02:00 GMT

Back in late 2004, Aaron Skonnard wrote an interesting article that details how a developer can create a lightweight, special-purpose web server without IIS. In his sample, Aaron chooses to host ASMX web services, but one could easily create other types of specialty web servers. Interestingly enough along with hosting the ASP.NET Runtime the other enabling technologies that allow for this functionality are none other than Microsoft's kernel-mode HTTP listener, Http.sys and the HttpListener classes of System.Net. Both of which are WNDP API's.

Run ASMX Without IIS

http://msdn.microsoft.com/msdnmag/issues/04/12/ServiceStation/

Now you may ask "why would I want to create my own web server"? And to that question we would have to agree that for the vast majority you would not want to for a production system. But the article and sample does demonstrate that it is indeed possible to create some of the basic web serving functionality with very little code and effort.