New NCL Features in .NET 4.0 Beta 2

아티클
07/20/2009

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.

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 https://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("https://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.

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>

<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 150bugs 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

Anonymous
July 23, 2009
I was stunned by level of maturity even Vs 2010 Beta 1 has attained. Eagerly awaiting for the release of Beta 2.
Anonymous
July 27, 2009
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?
Anonymous
July 27, 2009
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.
Anonymous
July 27, 2009
webby, this link may help you: http://www.pinvoke.net/default.aspx/iphlpapi/GetExtendedTcpTable.html
Anonymous
July 29, 2009
resolved in Beta2 problem with BinaryFormatter (Unable to find assembly)? https://connect.microsoft.com/VisualStudio/feedback/ViewFeedback.aspx?FeedbackID=119402
Anonymous
July 29, 2009
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.
Anonymous
July 29, 2009
thanks. release date is already known?
Anonymous
July 31, 2009
Sorry, I can't comment on the date at this time.
Anonymous
September 03, 2009
Are there any plans to have HttpListener work with SSL without having to use HttpCfg.exe? Maybe for .NET 4.5 or 5.0?
Anonymous
September 04, 2009
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.
Anonymous
September 09, 2009
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.
Anonymous
September 09, 2009
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?
Anonymous
September 17, 2009
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)
Anonymous
September 17, 2009
Thanks, Victor! We have a work item here tracking a similar request, so I'll add this context to it for planning.
Anonymous
November 20, 2009
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.
Anonymous
December 15, 2009
Thanks for the feedback. We have plans to address this inconsistency.
Anonymous
December 16, 2009
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
Anonymous
December 17, 2009
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"); 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.
Anonymous
January 19, 2010
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.
Anonymous
January 19, 2010
The comment has been removed
Anonymous
February 24, 2010
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.
Anonymous
February 25, 2010
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.

다음을 통해 공유