New NCL Features in .NET 4.0 Beta 2


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

Comments (22)

  1. Shalvin says:

    I was stunned by level of maturity even Vs 2010 Beta 1  has attained. Eagerly awaiting for the release of Beta 2.

  2. webby says:

    I am looking on how to get what port the webbrowser is using to establish connections (the port on the local machine)? Would the DnsEndPoint help?

  3. Aaron Oneal [MSFT] says:

    Unfortunately DnsEndPoint won’t help you there. It’s primarily a data structure representing a name and port pair.

    I don’t think we really have anything in the NCL that will help you monitor such information. Can you tell me more about your app & why it requires this functionality? Scenario info helps us better prioritize for the future. You can also use the e-mail link on the page toolbar at the top. Thanks.

  4. dedyshka says:

    resolved in Beta2 problem with BinaryFormatter (Unable to find assembly)?

    https://connect.microsoft.com/VisualStudio/feedback/ViewFeedback.aspx?FeedbackID=119402

  5. Aaron Oneal [MSFT] says:

    BinaryFormatter is owned by a different team, but yes, it appears that issue is resolved as of .NET 4.0 Beta 2. The linked Connect site has towards the bottom of the page pointers to the KB & hotfixes if you’re impacted by this.

  6. dedyshka says:

    thanks. release date is already known?

  7. Aaron Oneal [MSFT] says:

    Sorry, I can’t comment on the date at this time.

  8. Mike Lasen says:

    Are there any plans to have HttpListener work with SSL without having to use HttpCfg.exe?

    Maybe for .NET 4.5 or 5.0?

  9. Aaron Oneal [MSFT] says:

    Not in 4.0, but this is a feature we’re tracking and considering for a future release. I’d love to hear more about how you’re using HttpListener in your application.

  10. Victor Derks says:

    Would the SslStream in .NET 4.0 also allow to set the list of cipher suits it should use?

    Currently in .NET 3.5 the SslStream class will use a system wide configured list.

  11. Aaron Oneal [MSFT] says:

    We still use the system wide list. Do you have a need to control this per application, and can you tell me a little more about that scenario?

  12. Victor Derks says:

    Within the healthcare industry, there are a number of communication standards. Some standards restrict the allowed cipher suites when using TLS communication.

    Eg:

    IHE Technical Framework. IHE (www.ihe.net) is an organisation that specifies how to use existing standards for specific information systems interaction and also defines additional standard.

    For TLS it specifies two options (http://www.ihe.net/Technical_Framework/upload/IHE_ITI_TF_6-0_Vol2a_FT_2009-08-10.pdf,

    Chapter 3.19.6.2 & 3.19.6.3):

    TLS_RSA_WITH_NULL_SHA

    TLS_RSA_WITH_AES_128_CBC_SHA

    DICOM. DICOM (http://medical.nema.org/) is an organization that specifies standards for the interchange of medical images.

    For  TLS it specifies two options (ftp://medical.nema.org/medical/dicom/2008/08_15pu.pdf, Annex B1 & B3):

    TLS_RSA_WITH_3DES_EDE_CBC_SHA only

    TLS_RSA_WITH_AES_128_CBC_SHA with fallback to TLS_RSA_WITH_3DES_EDE_CBC_SHA

    In order to comply to the standards above, applications must be able to restrict the ciphersuites offered or accept to the allowed

    suites to make sure that the required suite is agreed upon. Restricting the system wide list is not acceptable because other

    applications may have different needs (eg. Internet Explorer on the same system wanting to access a secure web site)

  13. Aaron Oneal [MSFT] says:

    Thanks, Victor! We have a work item here tracking a similar request, so I’ll add this context to it for planning.

  14. feroze says:

    Windows7 & NTLM..

    Are we going to fix the bug that causes difference in behavior in NTLM, between IE and HttpWebRequest?

    When talking to a Windows7 machine, from a downlevel machine, IE seems to work fine (for NTLM auth) but HttpWebRequest fails. This is due to the 128bit requirement in Win7, combined with HttpWebRequest asking for SEAL+SIGN from SSPI.

    see:

    http://stackoverflow.com/questions/1443617/407-authentication-required-no-challenge-sent

    http://ferozedaud.blogspot.com/2009/10/ntlm-auth-fails-with.html

    Why dont you make this a configurable property, so that customers will be able to interop? Not everyone can change domain policy to not require 128bit encryption for NTLM.

  15. Aaron Oneal [MSFT] says:

    Thanks for the feedback. We have plans to address this inconsistency.

  16. Petr Horcicka says:

    Uri odstraňuje tečku adresáře – bude usnesení, ve finální verzi NET 4.0

    https: / / connect.microsoft.com / VisualStudio / feedback / ViewFeedback.aspx? FeedbackID = 480499

    nebo

    https: / / connect.microsoft.com / VisualStudio / feedback / ViewFeedback.aspx? FeedbackID = 386695

  17. Aaron Oneal [MSFT] says:

    Thanks for inquiring. We’re aware of those but I’m sorry to report we do not expect to have them resolved for .NET 4.

    In the mean time, there are a couple possible, though less than ideal workarounds.

    You can register your own scheme:

    GenericUriParser parser = new GenericUriParser(GenericUriParserOptions.DontCompressPath);

    UriParser.Register(parser, "myhttp", 80);

    Uri uri = new Uri("myhttp://contoso.com&quot;);

    If you really need the Uri constructed with "myhttp" to report out as "http" instead (such as in ToString() or AbsoluteUri) because you’re planning to pass it to a class like HttpWebRequest, you can derive a new class from GenericUriParser and override GetComponents() to do the scheme conversion. Jumping through these hoops is necessary because we don’t allow schemes to be changed once registered.

    The Connect entries above also mention alternate workarounds.

  18. Steve Nutt says:

    The ability to bind a UDPClient to a single IP address when a NIC has multiple IP addresses would a great new feature. I can’t seem to get this done in the current version of the framework.

  19. Aaron Oneal [MSFT] says:

    Steve, have you tried passing the address you want to use in the UdpClient constructor? There’s a sample for the overload on MSDN:

    //Creates an instance of the UdpClient class using a local endpoint.

    IPAddress ipAddress = Dns.Resolve(Dns.GetHostName()).AddressList[0];

    IPEndPoint ipLocalEndPoint = new IPEndPoint(ipAddress, 11000);

    try{

        UdpClient udpClient = new UdpClient(ipLocalEndPoint);

    }

    catch (Exception e ) {

              Console.WriteLine(e.ToString());

    }

  20. Salva says:

    I have created a new MVC2 project in VS2010 RC, and I can’t add the "DontUnescapePathDotsAndSlashes" parameter to the web.config ("The element ‘schemeSettings’ cannot contain child element ‘add’ because the parent element’s model is empty").

    Has it been removed from the release candidate?

    There are few references to this new parameter apart from this page, and I don’t know if it’s going to be in the final release of .Net 4, or if it has been replaced with something else.

  21. Aaron Oneal [MSFT] says:

    Thanks for reporting this issue. Most likely the feature is still activated by adding that parameter and what you’re seeing is a schema warning. We’re currently investigating.