In earlier parts we looked at the anonymous pipe and the fifo, which were predecessors similar in spirit to the Windows named pipe. A Windows named pipe is an inter-process communication mechanism that can provide either a one-way or duplex flow of data, organized as either a stream of bytes or a series of messages.
Creating a named pipe on Windows has significantly grown in complexity from what we’ve seen before as the number of options and capabilities of the named pipe system has increased. Here’s the named pipe creation function for comparison although I’m not going to go into detail on all of the parameters.
HANDLE WINAPI CreateNamedPipe( __in LPCTSTR lpName, __in DWORD dwOpenMode, __in DWORD dwPipeMode, __in DWORD nMaxInstances, __in DWORD nOutBufferSize, __in DWORD nInBufferSize, __in DWORD nDefaultTimeOut, __in_opt LPSECURITY_ATTRIBUTES lpSecurityAttributes);
The name parameter places the pipe somewhere in the file system, similar to the Unix fifo. On Windows though, the creation of pipes is limited to a special namespace, \\hostname\pipe\, which keeps pipes separate from other types of files and devices. The hostname portion of the pipe address allows pipe connections to span machines (next time we’ll see how to prevent remote access to a pipe, which is something that WCF does). For the local host, a dot is used instead of the hostname.
While a Windows named pipe can behave somewhat like a fifo, it also can behave somewhat like a socket. The pipe mode controls whether data is transferred through the pipe as a stream of bytes or as a sequence of messages. Instancing allows multiple pipe connections to be serviced using different threads where the pipe connections share the same pipe name. For example, you can construct a multi-threaded pipe server that talks to many clients, each of which connected to the same named pipe server address.
In summary, some of the things that make Windows named pipes different than the other named pipes we looked at are:
WCF uses only a portion of these capabilities and hides nearly all of the details of named pipe communication. Next time we’ll look at both how WCF uses Windows named pipes and how WCF makes a named pipe look even more like a socket.
Over on MSDN, Michele Bustamante will be doing a biweekly series called WCF Essentials on best practices and how to use WCF. The first two introductory articles are available now.
Getting Started with WCF (an introduction to the WCF Essentials series): This section will serve as a summary of the steps you will take to design, implement, host and consume WCF services. The purpose is not to explain the details behind each design choice or feature- but to make you aware that these are things you should consider. Later sections of this whitepaper will provide recommendations to narrow the choices you face.
WCF Templates and Tools: This section summarizes the available project templates, when to use each; and discusses the limitations and benefits of the core WCF tools.
The anonymous pipes that I talked about last time satisfy the basic requirements of an inter-process communication mechanism but have the considerable drawback of only working between two processes that share a parent-child relationship. The need for inter-process communication between two unrelated processes is reflected in another mechanism called a fifo (also sometimes called a named pipe).
A fifo is in many ways similar to a pipe on the surface but the two are different entities. Like a pipe, a fifo supports unidirectional communication from a writer to a reader. Unlike a pipe though, a fifo shares several characteristics with file-based devices, such as a name and an entry in the file system. A pipe is opened through the act of creating it while a fifo is first created and then opened for reading and writing by other processes.
The similarity between a fifo and a file device is actually substantial. In fact, the standard Unix system call for creating a fifo is int mknod (char *pathname, int mode, int device), which is the same system call for creating other kinds of devices. Creating most other devices requires special privileges though while ordinary users can create a fifo. A fifo is distinguished by the use of a particular flag bit in the mode, allowing the two uses to exist side by side. The pathname is what gives the name to the named pipe.
Once created, the fifo can be opened like an ordinary file, and after that can be read, written, or closed just like any pipe.
The Windows named pipe isn’t precisely the same as a fifo though, and those differences are what I’ll talk about next time.
Let’s start with the more ancient history and work over a few steps towards what pipes look like today. Pipes started out as inter-process communication mechanisms that provide a one-way flow of data.
The standard Unix pipe is created by the pipe system call int pipe (int*). The pointer parameter is really an array to which the pipe system call will write a pair of file descriptors for reading and writing from the pipe. Thus, you’re more likely to see the pipe system call written these days as int pipe(int[2]).
These pipes are anonymous pipes as their only representation is a file descriptor, which is a non-significant integer value that’s not portable between processes. The pipe will already be opened upon creation so the interesting operations to do with it are to read, write, or close the pipe.
This might lead to the question of how a pipe actually gets used for inter-process communication if the pipe has no name and there’s no way to open it from another process. The only way a file descriptor gets copied around is when a process is forked to create a child process. After calling fork(), both the parent and child process initially have the same file descriptors, effectively replicating the endpoints of the pipe elsewhere. One of the processes can then use the read file descriptor while the other process uses the write file descriptor. For example, you might build bidirectional communication between a client and server with the following approach:
These anonymous pipes are the fundamental building block of the pipeline for commands. The basic composition for running commands is to sequentially pipe data from one command to another. The command processor takes care of the step of creating the pipes and wiring them up to be the input and output of various commands in the pipeline.
Anonymous pipes are all well and good but it’s a big hindrance that they only work between two related processes. This spurred the creation of another inter-process communication mechanism that we’ll talk about next time.
Why are the members of a data contract expected in a particular order in order to be read?
The order of members is frequently used to build an expectation of what element might be appearing next. Knowing the possible order of data instead of potentially having to accept data in any order tends to make deserialization both faster and cheaper. In particular, you can frequently use an expectation of order to reduce or eliminate the buffering of data as compared to having to reorder the data after the fact. This is one of the many reasons for being able to specify the order property of a data member to be able to control the expected order.
This list is a bit different in places from what you’ve seen in the beta 1 release and there’s always a chance that things might change again.
The third part of the list covers some of the new features for service configuration. I haven’t mentioned some of the larger changes for simplified configuration and standard endpoints because those are already a part of the official beta 1 list.
I’ve defined my own XML namespaces for the members of a data contract and now when I generate the client proxies I get some ugly CLR namespaces for the types. How do I fix this?
The mapping from an XML or WSDL namespace to a CLR namespace is a mechanical transformation of breaking apart the authority and path of the XML namespace, doing minimal fix-ups to avoid illegal CLR type names, and spitting out a type in an equivalently delimited CLR namespace. The generated CLR namespaces might be neither pretty nor support CLS compliance needed for maximum portability.
You can fix those generated CLR namespaces though by overriding the mapping for an XML namespace. The svcutil program has a /namespace option that takes as parameters the target XML namespace and the CLR namespace that you would like to use instead. You can also use * for the target namespace to set the CLR namespace for all target namespaces without an explicit mapping. For example, you could say:
svcutil /namespace:*,Example.Contracts
If you’re using Visual Studio instead of svcutil, then you instead need to set the namespace mappings in the generated svcmap file in your solution. Inside the svcmap file is a NamespaceMappings collection to which you can add NamespaceMapping elements with attributes for the TargetNamespace and ClrNamespace. You aren’t able to use * for the target namespace though in an svcmap file because Visual Studio already has a wildcard definition and you’re not allowed to have conflicting definitions.
The broader Silverlight team is running a one day event here at Microsoft on September 17 to talk about Silverlight 3. It’s possible to sign up either for in-person attendance or for a live meeting presentation.
Here’s what’s on the agenda for the day:
If you’re interested, the sign up links are below for both ways of attending the event.
What would you most like to see at PDC for WCF?
Include as much commentary with your selection as you’d like. I generally don’t publish comments for survey questions but many people are auto-approved to show up. If you’d prefer your response to definitely not be visible to others, you can send it in the contact form.
Moonlight, an open source implementation of Silverlight for Linux systems, has released their feature complete beta corresponding to Silverlight 2 (and a small bit of Silverlight 3 too).
You can get the Moonlight 2 beta as either binaries or source code.
The second part of the list covers some of the new features and changes to existing features to improve service performance. These performance features are tailored to specific scenarios. Enabling these features when unnecessary might even slow your application down. You should measure whether your application actually gets some benefit before taking advantage of these.
Aaron Skonnard also has a list going on MSDN of new features for WCF in .Net 4. Our lists are going to look a bit different because I’m covering more, smaller features and Aaron’s list is targeted at beta 1. Some of the topics in the MSDN list though are:
Microsoft Research has a Network Monitor 3.3 plugin called TCP Analyzer that helps identify performance problems from a captured TCP session. TCP Analyzer takes a Network Monitor trace and performs visualization and analysis of the TCP connection. The analysis tries to identify what factor is most limiting to the transfer rate of the TCP connection, such as the rate of dropped packets, the latency in adjusting the transmission windows, or the available connection bandwidth.
As we get closer to the release of .Net 4 it becomes easier to talk about exactly what new features we’re planning to provide. This list is a bit different in places from what you’ve seen in the beta 1 release and there’s always a chance that things might change again.
The first part of the list comes from the area of WCF channels.
A month ago I asked for feedback on whether you’d be interested in occasionally seeing some longer articles with the tradeoff that the articles would come out less frequently. I got about 30 responses, with almost everyone interested in having longer articles and almost no one interested in changing away from a daily update schedule.
One compromise is to build the longer articles over time by seeding them from the daily updates. I’ve tried that out in a sample article on other technologies of interest to WCF developers. I’ve gotten started with the ASP.NET MVC and Managed Services Engine technologies that I talked about recent, but you might imagine seeing over time additional entries such as the Managed Extensibility Framework and the Windows API Code Pack. The goal of the summary page isn’t to be comprehensive but to tie together many related posts to make the content easier to find.
You might also imagine seeing similar types of summaries for topics such as WCF/Silverlight releases, conferences, or technical topics like IIS troubleshooting.
Let me know if you love or hate the first edition.
Going along with Windows 7, the final version of the Windows API Code Pack was released last week. The code pack is a way to provide access to Windows features that lack a managed interface in the framework today, primarily for things added in Windows Vista and Windows 7. For example, the code pack adds managed wrappers around native Windows APIs allowing you to integrate with newer shell, dialog, power, and DirectX features.
The API that WCF programmers are most likely to be interested in is the Network List Manager interface that I talked about when it was added to the code pack beta. The network list manager service tracks information about all of the network connections the machine has seen and knows whether they’re currently connected or disconnected. This allows you to enumerate all of the computer’s connections and query properties such as the IP address, network adapter, protocol versions, gateway settings, and whether the connection joins the machine to a Windows domain.
Most people will want to use the most recent SDK since it supports the last several framework and operating system versions, but if you're looking for the older releases, here they are:
The 2009 Professional Developers Conference will be held this year from Tuesday November 17th to Thursday November 19th, located again at the Los Angeles convention center. A pre-conference workshop day happens ahead of time on Monday. Workshops are a more in-depth look at particular technologies while the main conference is built around breakout sessions and keynote presentations.
The scheduled workshops are:
The schedule for the rest of the sessions is completely fictional. If you're signing up now it's because you know you want to attend regardless of who's saying what. A reasonably accurate list of sessions generally starts shaping up closer to the event.
It’s been a year since I last talked about the Managed Services Engine, which is a prebuilt solution for virtualizing web services through metadata inspection and message routing. Since then they’ve released two more CTPs, the most recent one being the May 2009 CTP.
You’ll find guides covering installation, the technical details of the services engine, and securing virtualized services at the same place.
Aaron Skonnard has an article in MSDN Magazine covering virtualization of cloud and REST services with the Managed Services Engine for those interested in a walkthrough. A whitepaper that greatly extends that article is also available.
The latest information about the Managed Services Engine can be found in the list of supporting technologies.
MVC 2 resources:
MVC 1 resources:
The MVC forums cover both MVC 1 and 2.
The latest information about ASP.NET MVC can be found in the list of supporting technologies.
The second version of ASP.NET MVC is already underway (it’s on the same type of frequent release schedule as Silverlight). MVC is a model-view-controller framework on top of the existing ASP.NET runtime that separates display and application logic as well as makes test-driven development of ASP.NET applications easier. MVC could be used with a variety of types of web applications but is frequently associated with REST applications.
The MVC 2 Preview 1 runs on Visual Studio 2008 with .Net 3.5 SP1 and you can have both MVC 1 and MVC 2 installed at once.
If you’re not looking for a preview release, you can get the original ASP.NET MVC 1.