Previous: Finishing touches: Make your .NET app shine with professionalism
Subscribe to the RSS feed
Or subscribe by email
Wyatt Says... is a collection of design articles by Wyatt O'Day. I want to help you make your programs great and your users happy.*
*Or as we say in New England, "wicked friggin' happy"
Wyatt Says...
2 months ago we released wyBuild & wyUpdate v2.5. This release adds a free automatic updater control for C# & VB.NET apps. And because we wanted to keep things simple we left the wyUpdate.exe to do all the hard work (checking, download, installing) in the background while the AutomaticUpdater control is visible on your app’s main form.
We wanted the AutomaticUpdater to be able to control the update steps, view progress, and cancel the updating. But we also wanted to keep all the updating logic in the wyUpdate.exe. For this to be successful we needed a way for the AutomaticUpdater control to talk to wyUpdate.exe while it’s running.
The Answer: Inter-process communication (IPC)
Inter-Process communication is a fancy computer science way of saying “processes that can talk to each other”. Google Chrome uses IPC to communicate between tabs of the browser & plugins. It’s a simple way to keep parts of your program isolated from crashes.
For instance, if a tab of Google Chrome crashes only that single tab is killed. The rest of your tabs will continue to function normally.
Lots of bad ways to do IPC
Now that you know what inter-process communication is, let me tell you the worst ways to do it.
- Shared memory: Difficult to set up & difficult to manage.
- Shared files / registry: Very slow due to the writing & reading to/from disk. Difficult to manage.
- SendMessage / PostMessage: Locks up the UI thread while the message is processed. Messages are limited to integer values. Can’t communicate from a non-admin process to an admin process. Assumes that your processes have a window.
Named Pipes
Inter process communication using named pipes is what Google Chrome uses and what we use for wyUpdate and the AutomaticUpdater control. Let me teach you about named pipes.
“Like Mario’s pipes?”
Exactly like Mario’s pipes. Except, instead of jumping Mario through the pipe, you push data through the pipe:
What do you put in the pipe?
You can transfer any data between your processes. So what data should your transfer? The answer is “it depends”. The rule of thumb is to keep it short, and keep it simple. Here’s what we do with the named pipe between wyUpdate and the AutomaticUpdater control sitting on your application:
- Command codes: The AutomaticUpdater can command wyUpdate to check for updates, download the updates, extract the update, and install the update, or cancel any current progress.
- Responses: wyUpdate can tell the AutomaticUpdater if there’s an update available, what changes there are in the update, and the progress of the current step (e.g. downloading).
With this simple setup the AutomaticUpdater control that’s on your application is completely isolated from wyUpdate.
Get the C# source
Download the named pipes C# source. It works with .NET 2.0, 3.0, 3.5 on Windows 2000 – Windows 7.
There are two files that do all the work: PipeServer.cs and PipeClient.cs. We use the PipeServer.cs file inside wyUpdate, and we use the PipeClient.cs file inside the AutomaticUpdater control.
Also included in the zip file is a simple messaging program to demonstrate communication between two separate processes:
Tell me what you think in the comments. I want to hear from you.
Subscribe to Wyatt Says...
Subscribe to the 'Wyatt Says...' RSS Feed and keep up to date on on my articles on updaters, usability, open source C# components, and soon anti-piracy.
Upcoming articles:
- 7 days of Windows 7: Tips, Tricks, and Controls to get your C# and .NET apps Windows 7 ready October 14th - October 22nd
- Quick C# Tip: Adding animation to your Windows Forms app
- Building a Great Updater Part 2: Adobe Updater, Inconsistency is Thy Name
Subscribe now, and don't miss out. Or subscribe to Wyatt Says... by Email
Did you consider using anything in System.Runtime.Remoting? With .NET remoting the client can call functions on the remote object as if it was a local object. Its also easy to change the underlying IPC mechanism to TCP, Pipes, Http, or shared memory.
I had considered using System.Runtime.Remoting, however we had a few requirements that the Remoting namespace didn’t match. Namely we needed the ability for Admin processes to talk to Non-admin processes & vice versa. This is a real problem on Vista & Windows 7. Plus, we also needed the Server to detect when a client disconnect & the clients to know when the server disconnected (even if a message saying as much wasn’t sent).
The problem with the Remoting namespace is that it’s too high-level for our particular problem. But I suppose it’s fine if you don’t need these problems solved.
What are the differences between named pipes and message queues?
That’s what I was talking about when I mentioned SendMessage / PostMessage. There are a lot of differences between named pipes and message queues. The one reason I didn’t use message queues (besides the inability for non-admin processes to talk to admin processes) was the message queue deadlock problem.
In short, message queues are a really poor way to do IPC on Windows.
Msmq is not the only message queue that can run on windows
I wasn’t aware of any other message queuing system on Windows. I based all my research on non-third party IPC systems available on Windows 2000+ which work with .NET 2.0+.
I suppose you could use some POSIX wrapper to support Unix style message queues, but these implementations likely use named pipes or sockets as the backend.
MSMQ (like Paco was referring to) and SendMessage/PostMessage (like Wyatt is talking about) are completely different things.
MSMQ is total overkill for a simple lightweight job like the example.
IE8 is multi-process as well (before Chrome, BTW :-). Do you know which approch IE use?
The process model in IE8 is described in detail in both Scott Hansleman’s post & on the IEBlog. Neither of the posts mention what IPC model IE8 uses. However, and it might be just me, but Hanselman’s wording when he mentions Google Chrome using named pipes seems to imply IE8 also uses named pipes:
Great article and awesome work.
WCF also supports named pipes……
Thanks Steven.
Yes, it does. But wyUpdate & the AutomaticUpdater control are written for .NET 2.0, and WCF came with .NET 3.0. It would have cost us customers & caused our existing customers a hassle if we decided to up the requirements to .NET 3.0.
Plus, my solution is easier to use.
Excellent post, and thank you very much for providing the source code.
I am unsure what use I will have for named pipes in any of my current projects, but I am almost certain this will be extremely beneficial some day down the line!
Cheers!
What license is associated with the code? Is it okay for commercial use?
My pleasure, Tom.
I didn’t state it explicitly, but the source code is licensed under the BSD license. I should probably add that to the zip file.
So yes, you can use it in commercial products.
Excellent, thank you very much!
I found something interesting while using this code. I wanted to use IPC for sending parameters to another application (along the lines of allowing only a single instance), but found that if I tried to do this without any user interaction, it would become very flaky and it only received two messages of the many that I sent. Then, I figured out why. You need to have the thread sleep (I have it set to a second). I assume this doesn’t happen in your provided demos because at least 1 second passes by the time you move the mouse from the Connect button to the Send button.
SendMessage(…) returns a boolean. True if the message was sent successfully, false if it wasn’t. To avoid the sleeping, just put the SendMessage in a simple loop.
// remove the retryTimes if you want it continually retry until success
int retryTimes = 0;
while(!client.SendMessage(byteArr) && retryTimes < 5)
{
Thread.Sleep(200);
retryTimes++;
}
This way the thread will only sleep on failure.
Great article, you’ve got yourself a new subscriber