Update: 2009-11-02 The podcast is now available on Channel9 too.

At a recent GL.NET user group meeting I met Eric Nelson (), and he asked me to write an article for the MSDN Flash newsletter (), so I did. I expanded on my previous post regarding Memory Mapped Files in .NET 4, and that article has been published today.

You should be able to read the entire newsletter on-line, however, at the time of writing this post the current newsletter link was showing last month’s newsletter, but I’m sure that will change very soon. However, I’ve put a copy of the article at the end of this post, if you’re interested in reading it.

I also did the podcast which accompanies the newsletter with Eric, and it was an absolute blast. I’ve not done anything like that before so it was quite a departure from my normal working day. You can find all the podcasts here.

As usual if you have any comments, questions, flames, enhancements I would love to hear from you. In the meantime, think deeply and enjoy.

---

Memory Mapped Files with .NET 4

.NET 4 is on its way and there are many new features being blogged about, such as Parallel Computing and Dynamic Languages but the new feature that caught my eye was Memory Mapped Files. The idea of mapping memory to a physical file on disk has been around for a very long time on the Windows platform but this capability has not been available natively in managed code before and instead needed to be accessed via P/Invoke.

You might be wondering why you would wish to map memory on to a file, and why after numerous versions of the .NET Framework we need this feature now. To answer the first question it is worth pointing out that a memory mapped file is one of the most efficient ways for multiple processes on a single machine to talk to each other. What is more, most Windows IPC based communication mechanisms, such as COM, DDE, Sockets, Pipes and even Windows Messages themselves all sit on top of Memory Mapped Files. Another reason for using Memory Mapped Files is for processing extremely large files, as they enable random and concurrent access to a file without the need for seeking.

The large file processing is lovely and all that but I want to talk about inter-process communication on a single machine for a moment. There are many available options. You could go old school by using classic .NET Remoting for cross AppDomain communication by using transparent proxies, MarshalByRef and ContextBoundObject classes. You could code this using WCF and Named-Pipes; as well as all the available cross-machine techniques such as streams and sockets, or Web services by using one the various flavours of WCF Bindings or not forgetting plain old ASMX.

Given this wealth of options, when should you use Memory Mapped Files (MMF) over, say, WCF? For me, the answer is simple: it depends. As always with new technologies your millage may vary, but I think as a general rule, for IPC on a single machine MMF is the way to go; if only for the relatively simple programming model (see my blog post for a simple code example) and performance characteristics. Sometimes, when you need to send 4 bytes, you should just send 4 bytes; not a Soap envelope, encoded with a myriad of WS-* standards and human readable mark-up running into hundreds and hundreds of bytes – just to send your 4 byte message.

Memory mapped files will be my first choice for the scenarios that were previously reserved for WCF and Named Pipes, well, they will be as soon as .NET 4 ships. However, if you even suspect that at some point you might need your communication to spread across machines, then you are better off starting with WCF and named-pipes, because supporting cross machine communication in the future should simply be about making changes to configuration not recoding the communication layer.

That brings us back to the second question of: why now, why in .NET 4 and not some previous release. For that, we can only guess; but I am glad they finally did! You can find out more in the preliminary MSDN documentation.

Paul Jackson
Blog: https://compilewith.net
LinkedIn:

---