In a few days I'll be heading off to MIX08 with a few members of the Astoria team to check out all the cool work going on that is targeting the web and to give one of a few presentations on the ADO.NET Data Services Framework.
At MIX07 we discussed Astoria in the context of an incubation project and this year we'll show the production version of the bits and show some interesting integrations with Windows Live ..... check out my blog post to the Astoria team blog for details..
see you at MIX,
Mike
My blog has been slow over the last few months, but this time its not because I haven't been blogging :). I've been busy posting about the new Astoria (newly renamed to ADO.NET Data Services) CTP.
Check out this post for where to get the latest Astoria bits from: "ADO.NET Data Services ( Project Astoria ) CTP is Released"
We've also started a blog series on the feature set of the CTP. The first post I did in the series was on the authorization / validation infrastructure in the system. You can check that out here: "ADO.NET Data Services Dec2007 CTP - Validation and Access Control"
We look forward to hearing what you think...
-Mike
I'll be presenting an Astoria talk at the upcoming Dev Connections conference in Las Vegas and later in November at Dev Teach in Vancouver, BC. If you are interested in chatting about Astoria, I'll be wondering around the conference most of the time. See you there!
My blog has been silent for a while as I have been switching focus and moved from the Windows Networking group to the Data Programmability (DP) group in the SQL Server division at MS. Currently, my main area of focus in DP is the Astoria project. For an detailed overview of Astoria, please see our team blog here. In short, Astoria is about providing simple and efficient data services for todays web-enabled applicatoins: The new wave of web applications are built on technologies such as AJAX and Microsoft Silverlight that enable developers to build better, richer user experiences. These technologies bring a shift in how applications are organized, including a stronger separation of presentation from data. The goal of Astoria is to enable applications to expose data as a data service that can be consumed by web clients within a corporate network and across the internet. The data service is reachable over HTTP, and URIs are used to identify the various pieces of information available through the service. Interaction with the data service happens in terms of HTTP verbs such as GET, POST, PUT and DELETE, and the data exchanged in those interactions is represented in simple formats such as XML and JSON."
The components that make up the Astoria project are:
- A set of downloadable bits that you can run on your web server to create you own Astoria services
- A .net framework and Silverlight 1.1 client library that raise the abstraction from simple HTTP requests
- An experimental online service (just released) that allows you to create your own 100MB Astoria data service hosted by us
One of the interesting pieces of the Astoria design cycle is that we plan to be as transparent as possible. Pablo, the Tech Lead on the team, explains what we mean by this pretty well on his blog. He states:
"The technology and needs in the web space are broad and move fast. As we are building technology for that space with Project Astoria, we wanted to make sure we do it in a way that works well with the nature of the environment and the developer community we are targeting. One of the things we'll try is to be as transparent as possible with the design process. Our plan is that as we discuss design issues in our design meetings, we will post the discussions on the Astoria Team blog as well. Not just the conclusions, but the discussions themselves, even before we made a call. We were also thinking of posting our regular meeting notes publicly as well."
Cheers
Mike
Ok, this will conclude my string of survey posts (I promise).
As we plan future additions and changes to Winsock LSPs and, more broadly, network filtering on Windows, we would like your input on the good, the so-so and ugly of Winsock LSP development and deployment. Please take a few minutes to share your feedback with us. Each response will be directly reviewed by the LSP team and used to help share the future direction of network filtering.
The survey can be accessed here
NOTE: The survey is anonymous, unless you choose to "opt-in" and provide your contact information
Cheers,
Mike
We have recently launched a survey to get your feedback regarding the network development experience on Windows. If you have written a network-aware application (commercial product, as a hobby, etc) we would like to hear from you.
NOTE FOR WINSOCK API USERS: The survey has a section devoted to Winsock API usage. I look forward to learning about all the ways in which Winsock is being leveraged in your applications and what you would like to see added or changed in the future.
I have yet to write the third part in the series on writing ip agnostic apps, but in the meantime, Anthony Jones (Winsock Developer/Guru) and I chatted with Charles about the topic on Channel 9: http://channel9.msdn.com/Showpost.aspx?postid=265664
We had a great time creating the video. It jumps around to many topics, but I suppose that is what we get when Charles stops by, says hi while powering on his camera and then hits record :)
With the adoption of IPv6 ever increasing (ie. it is the preferred protocol on Windows Vista) it is important that network aware applications support IPv4 and IPv6. I have started a series of posts on our team blog discussing how one can go about writing internet protocol agnostic code....
Part 1 and Part 2 have already been posted......
The System.Net.HttpWebRequest class in the .Net Framework implements a HTTP stack in managed code. One of the features of the stack is that it supports HTTP pipelining. Pipelining is the ability for an HTTP client application to send multiple requests on a connection before the server responds to the first request. Wikipedia describes pipelining here: http://en.wikipedia.org/wiki/HTTP_pipelining
This post is to give seasoned users of the HttpWebRequest class a heads up about a design change in the way we handle pipelining in version 2.0 of the .Net Framework. In 2.0 we throttle pipelined requests as follows:
If the number of sent pipelined requests reaches 10, no more requests will be written to the server (pipeline “paused”). When the number of written pipelined requests drops to 5 or less, because of processed responses, more requests will be written to the server if possible (pipeline “unpaused”). Of course all the other factors influencing pipeline-ability are still considered. The values of 10 and 5 noted above are not configurable by the developer. This throttling mechanism was introduced so as to not overwhelm servers after a number of requests are queued up on the server side.
We have made a number of improvements in Winsock for Windows Vista. Recently we have detailed a few of these on our team blog:
"Introduction to WSK" - a new kernel mode socket API: http://blogs.msdn.com/wndp/archive/2006/02/24/538746.aspx
"Winsock and Vista User Account Control": http://blogs.msdn.com/wndp/archive/2006/02/22/537082.aspx
"Categorizing LSPs and Applications"
http://blogs.msdn.com/wndp/archive/2006/02/09/529031.aspx
I have been involved in a number of forum posts and mail threads lately regarding reading data from a socket. The typical situation is as follows:
A TcpClient object is connected to a remote party. The application gets a reference to a NeworkStream object by calling the TCPClient’s GetStream method. The remote party begins sending messages and the NetworkStream's read method is used to read the data sent over the network. All is well so far:
Now, to avoid waiting in a blocking read call forever, one can set a timeout in the call to NetworkStream.Read( ). If no data arrives within the timeout specified, an exception is thrown.
At this point one may be tempted to catch the exception and then reissue the read on the same NetworkStream. This strategy can lead to unexpected errors. The best thing to do is to now treat the NetworkStream (socket) as being in an unstable state. This is because when the underlying stack times out, the underlying I/O read gets cancelled. If data comes in at the same time, the data will be lost, resulting in a corrupted data stream.
A better approach is to catch the exception, close the socket or TCPClient and reconnect if necessary.
TcpClient client;
NetworkStream stream;
byte[] readBuffer = new byte[1024];
try
{
// Create a TcpClient.
// Note, for this client to work you need to have a TcpServer
// connected to the same address as specified by the server, port
// combination.
Int32 port = 13000;
client = new TcpClient(server, port);
// Get a client stream for reading and writing.
// Stream stream = client.GetStream();
stream = client.GetStream();
// set read timeout
stream.ReadTimeout = 60000;
stream.Read(readBuffer,0,readBuffer.Length);
……
} catch (IOException e){
// the read timed out
// At this point the socket should be considered in a bad state.
}
In version 2.0 of the .Net Framework, we added a new namespace under System.Net called NetworkInformation. Among many other goodies, one can use this namespace to listen for IP addresses changes on the host. The code below listens for addresses changes and prints a message when a change occurs along with the operational status of each interface on the host:
using System;
using System.Net;
using System.Net.NetworkInformation;
namespace Examples.Net.AddressChanges
{
public class NetworkingExample
{
public static void Main()
{
NetworkChange.NetworkAddressChanged += new
NetworkAddressChangedEventHandler(AddressChangedCallback);
Console.WriteLine("Listening for address changes. Press any key to exit.");
Console.ReadLine();
}
static void AddressChangedCallback(object sender, EventArgs e)
{
Console.WriteLine("Addresses Change Event Raised");
NetworkInterface[] adapters = NetworkInterface.GetAllNetworkInterfaces();
foreach(NetworkInterface n in adapters)
{
Console.WriteLine(" {0} is {1}", n.Name, n.OperationalStatus);
}
}
}
}
NOTE: Due to timing in the underlying operating system, if you plan to inspect what addresses are available as soon as the callback fires, you may need to sleep for 1 second. If you don't sleep, when you inspect the current set of addresses the changes may not have taken effect.
Generally I don't like making a post that only includes links to other posts, but I'm making an exception for this case. In this (http://blogs.msdn.com/malarch/archive/2005/11/18/494769.aspx) article Malar explains how to create a single socket that can listen for IPv6 and IPv4 connections. This ability is due to the new TCP/IP stack in Vista. Malar uses the following code to demonstrate creating such a socket:
static void Main(string[] args)
{
Socket sock = new Socket(AddressFamily.InterNetworkV6, SocketType.Stream, ProtocolType.Tcp);
sock.SetSocketOption(SocketOptionLevel.IPv6, (SocketOptionName)27, 0);
sock.Bind(new IPEndPoint(IPAddress.IPv6Any, 8000));
sock.Listen(4);
Socket client = sock.Accept();
Console.WriteLine("Client has connected successfully with the server");
}
The socket option being set above is pound (#) defined in Winsock as IPv6Only; however, since this is a Vista feature, we don't have the name encapsulated in the SocketOptionName enumeration yet. I should note, the above is not supported in Whidbey, but we are working to enable this scenario in a future release.
In version 2.0 of the .Net Framework, we (System.Net) changed how we parse HTTP traffic. The change has gone to a more strict parsing model. One example, is we now require a CRLF (carriage return, line feed) at the end of each line. While these changes were done to improve the security of our HTTP stack, it has the negative effect of causing some applications to see exceptions thrown where they didn't previously. If you find the parsing of the HTTP headers to be too strict, you can revert the strictness of our parsing to improve app compatibility. This is done via an application configuration file setting as shown below
Hierarchy:
<configuration> Element
<system.Net> Element (Network Settings)
<settings> Element (Network Settings)
<httpWebRequest> Element (Network Settings)
<httpWebRequest
maximumResponseHeadersLength="size"
maximumErrorResponseLength="size"
maximumUnauthorizedUploadLength="size"
useUnsafeHeaderParsing="true|false"
/>
Additional note about UnSafeHeaderParsing:
By default, the .NET Framework strictly enforces RFC 2616 for URI parsing. Some server responses may include control characters in prohibited fields, which will cause the System.Net.HttpWebRequest.GetResponse method to throw a WebException. If useUnsafeHeaderParsing is set to true, System.Net.HttpWebRequest.GetResponse will not throw in this case; however, your application will be vulnerable to several forms of URI parsing attacks. The best solution is to change the server so that the response does not include control characters.
Prior to the .NET Framework version 2.0, applications could register a component to handle FTP requests using System.Net’s extensible pluggable protocol framework. Components for handling different web requests are registered by associating the component with a specific URI prefix. Any web request that matches that prefix would then be handled by that component. In version 2.0 of the .NET Framework, System.Net now supports an FtpWebRequest component that is registered by default for the “ftp:” prefix. Any applications that are registering for this prefix (prior to this release) could now be broken because the prefix (FTP) is already taken.
There is a workaround for this issue. It is as follows:
Update the application configuration file to remove the default FTP pluggable protocol prior to registering your own FTP component:
<system.net>
<webRequestModules>
<remove prefix = “ftp:” />
</webRequestModules>
</system.net>
I hope this information helps to make your applications transition to Whidbey smooth as silk :).
