Using Named Pipes for Tracing

• Download demo project - 37 Kb
• Download source - 17 Kb

Introduction

Traces are very useful tools for debugging purposes, especially if the program runs as a release version. It is easy to save the traces for a single application. But it needs a little work to receive the traces of multiple processes or even threads running at the same time in one single file or window. The example given here describes an elegant way to solve this problem. It uses "named pipes" for interprocess communication. Each process sends its trace data to one central special listener process. For the processes sending traces it doesn't matter if this listener process does or does not exist.

Background

A Named Pipe is a high level mechanism for the communication between processes even if they are running on different computers linked by a network. It hides all the communication details and offers two sides: One side to put data in and one side to read it out, but it can also be used bidirectional.

For building up a communication line, a process creates a pipe with a unique name. Using this name another process can connect to this pipe. Because a named pipe is a link between only two processes, it needs a set of named pipes to communicate with more then two processes at the same time. Each instance of these named pipe can use the same name.

The reading or writing of data to a pipe can be done with the normal set of Windows commands used to read or write data to a file. Like the normal file operations named pipes can be accessed in a blocking (= synchronous) or nonblocking (= asynchronous) mode. This example uses the synchronous communication mode because it is especially simple to use: The function calls to read or write data don't come back until the communication operation has finished. To allow communication with multiple processes it uses one thread for each pipe. Every time a new process connects to the listener, it creates a new pipe allowing the next process to connect with.

Using the code

For sending a trace, there is just a very easy interface needed: Building up the communication with Connect and sending traces with MakeTrace. The usage is demonstrated in the simple dialog based application TraceSender. You may start multiple instances of this program to generate more traffic.

class CTracer  
{
public:
  CTracer();
  virtual ~CTracer();

  bool Connect();
  bool MakeTrace(const char* pStr,...) const;    // use like printf(...)


private:
  HANDLE m_hPipe;

};

Because of its multithreading capability the mechanism for receiving traces is a little bit more complicate to implement. But its usage is as simple. This demonstrates the simple console application TraceListener:

#include "stdafx.h"

#include "conio.h"


#include "TraceCollector.h"


BOOL OnTrace(const char* pStr, DWORD nLength)
{
  _cputs(pStr);
  _cputs("\r\n");
  return TRUE;
}

int main(int argc, char* argv[])
{
  CTraceCollector tracer(OnTrace);
  tracer.Run();

  _getch();
  return 0;
}