We’re introducing some new features starting with .NET 4.0 Beta 2 that you may find useful. Additional information will be available on MSDN and in subsequent articles. If you have any questions or comments, let us know!

Sockets

DnsEndPoint

This feature was first introduced in Silverlight 2 and it allows you to connect to a listening socket by DNS name, simplifying the connect experience. Now you can take advantage of this in .NET as well.

Before

IPAddress[] IPs = Dns.GetHostAddresses("www.contoso.com");

foreach(IPAddress ip in IPs) {
try {
  socket.Connect(new IPEndPoint(ip, port));
 
break; 
}
catch(SocketException) { continue; }

}

After

socket.Connect(new DnsEndPoint("www.contoso.com", port));

IP Version Neutrality

Starting with Windows Vista, the TCP/IP stack has features which allow you to write sockets applications that can transparently handle multiple versions of the Internet Protocol. This works by creating an IPv6 socket and setting the IPv6Only socket option to false. Once set, the IPv6 socket is also able to accept IPv4 traffic. This frees your application from the traditional model of having to create multiple sockets for each IP version.

Socket socket = new Socket(AddressFamily.InterNetworkV6, SocketType.Stream, ProtocolType.Tcp);

socket.SetSocketOption(SocketOptionLevel.IPv6, SocketOptionName.IPv6Only, 0);

socket.Bind(new IPEndPoint(IPAddress.IPv6Any, 8000));
socket.Listen(5);
Socket client = sock.Accept();

SSL Encryption Policy

Traditionally SSL is used both for encryption and for authentication / message integrity. In some cases, however, encryption is not required or desired. This could be for interoperability with other systems or performance reasons. Therefore, you can now change the default encryption policy for SSL. In some circles, this is also referred to as using a “null cipher”.

namespace System.Net.Security

  public enum EncryptionPolicy 
  { 
    RequireEncryption,
// always require encryption 
    AllowNoEncryption,
// prefer full encryption; allow none if server agrees
    NoEncryption      
// require no encryption; fail if server requires it
  }
}

This setting can be configured in the following places.

  • SslStream
  • ServicePointManager for HttpWebRequest, FtpWebRequest, SmtpClient
  • Machine.config or app.config

SmtpClient

SSL Configuration

It is now possible to enable explicit SSL in SmtpClient via application config in addition to the runtime option that was already available.

<configuration>
  <system.net>
    <mailSettings>
      <smtp deliveryMethod="network">
        <network
          host="localhost"
          port="25"
          defaultCredentials="true"
          enableSsl="true"
        />
      </smtp>
    </mailSettings>
  </system.net>
</configuration>

Header Encoding

Prior versions of .NET restricted headers to ASCII encoding. A new MailMessage.HeadersEncoding property will allow for an alternate encoding to be specified for the headers added to the MailMessage.Headers collection.

Multiple ReplyTo Addresses

The MailMessage.ReplyTo property only allows a single address to be added. We’re adding a new collection property called MailMessage.ReplyToList to support multiple addresses.

HttpWebRequest

64-bit Range Header Support

When a client program makes an HTTP request, that request includes a number of headers which determine how the server will respond. One of those headers is the Range header as described in RFC 2616 (obsoletes 2068). The Range header on a request allows a client to request that it only wants to receive some part of the specified range of bytes in an HTTP entity. Servers are not required to support Range header requests.

An example of a range header in the HTTP request is:

Range: bytes=1024-2047

Some of the uses of the range header include:

1. Manually maintaining “QOS” (quality of service) for streaming media. For example, a sophisticated movie viewer program might download the video and audio of a movie separately, downloading the “next” pieces only when needed

2. Manually handling file caching for interrupted downloads

The existing framework includes a set of public HttpWebRequest.AddRange methods as specified on MSDN at http://msdn.microsoft.com/en-us/library/system.net.httpwebrequest.addrange.aspx.

Additional overloads supporting Int64 ranges have been added.

Date Header Support

A new HttpWebRequest.Date property has been added to support setting of the HTTP Date header.

Host Header Support

A new HttpWebRequest.Host property has been added to allow configuration of the HTTP Host header. This header can be used during testing and with load balancers, for example, to ensure the TCP connection is established to a particular IP address but that the client can still address the intended web site at the specified HTTP server endpoint. For example:

var request = WebRequest.Create("http://127.0.0.1/") as HttpWebRequest;
request.Host = "contoso.com";
var response = request.GetResponse();

WebRequest Performance Counters

Troubleshooting a server application can be difficult, and one key tool for this is the Windows Performance Monitor. With the addition of new performance counters for WebRequest, this is now easier. The diagram below (click for a larger view) shows the new counters and the points in the lifetime of an HttpWebRequest where they are updated.

image 

NAT Traversal

The term NAT traversal refers to the ability for client devices to address and communicate with listening devices behind a NAT. This turns out to be an incredibly useful thing to do for games, peer-to-peer, and a variety of other applications. A subsequent article will go into full detail about what is available, but here’s a quick preview of one aspect of this feature.

If you’re using TcpListener or UdpClient, just pass into the constructor IPAddress.IPv6Any, then call AllowNatTraversal with a value of true to support NAT traversal in your application.

var listener = new TcpListener(IPAddress.IPv6Any, 8000);
listener.AllowNatTraversal(true);
listener.Start();

Escaped Character Support in Uri

With REST becoming a more popular way of creating web services, and with the key role Uri plays in resource identification, we are providing a way to relax some of the canonicalization performed by our current http(s) scheme parser. If you have encountered issues with special characters such as / or \ being unescaped, you now have the following configuration options at your disposal.

<?xml version="1.0" encoding="utf-8" ?>
<configuration>
  <configSections>
    <section name="uri" type="System.Configuration.UriSection, System, Version=4.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089" />
  </configSections>

  <uri>
    <schemeSettings>
      <add name="http" genericUriParserOptions="DontUnescapePathDotsAndSlashes" />
      <add name="https" genericUriParserOptions="DontUnescapePathDotsAndSlashes" />
    </schemeSettings>
  </uri>

  <system.net>
    <settings>
      <httpListener unescapeRequestUrl="false" />
    </settings>
  </system.net>
</configuration>

This will allow you to turn off this form of escaping in Uri and also in the RequestUrl received from HttpListener. The latter setting will also impact application hosted WCF services using HTTP bindings since those are built on HttpListener.

Bug Fixes

No release would be complete without bug fixes, and we’re addressing plenty of those! The NCL team has fixed over 150 bugs as of this milestone. Our focus during triage was on:

  • Stability (fix hangs, crashes and improve long-running/data center scenarios such as fix memory leaks)
  • Performance
  • RFC compliance with URI, FTP, HTTP, SMTP
  • Internationalization (better handling of Unicode characters, etc.) in URI, FTP, HTTP, SMTP
  • IPv6 connectivity
  • Customer reported bugs through our Connect, MSDN Forums, and other channels

Please try out the new release when available and let us know what you think!

~ NCL Team