Трубная связь C++

Несколько простых фрагментов от клиента (вашей службы) и сервера (уведомителя) [Примечание. Это адаптировано из проекта, который я сделал некоторое время назад, на который, в свою очередь, сильно повлияли образцы MSDN из CreateNamedPipe. и др.]:

Сторона сервера:

HANDLE hPipe = INVALID_HANDLE_VALUE;
bool bConnected = false;

 hPipe = CreateNamedPipe( L"\\\\.\\pipe\\nhsupspipe",
                          PIPE_ACCESS_DUPLEX,
                          PIPE_TYPE_MESSAGE | PIPE_READMODE_MESSAGE | PIPE_WAIT,
                          PIPE_UNLIMITED_INSTANCES,
                          sizeof( Message ),
                          0,
                          0,
                          NULL );

 // failed to create pipe?
 if( hPipe == INVALID_HANDLE_VALUE ){
   return -1;
 }

 // Wait for the client to connect; if it succeeds, 
 // the function returns a nonzero value. If the function
 // returns zero, GetLastError returns ERROR_PIPE_CONNECTED. 
 bConnected = ConnectNamedPipe( hPipe, NULL ) ? true : ( GetLastError() == ERROR_PIPE_CONNECTED );

 if( bConnected ){
  while( true ){ 
   unsigned long ulBytesRead = 0;
   // read client requests from the pipe. 
   bool bReadOk = ReadFile( hPipe,
                            &message,
                            sizeof( message ),
                            &ulBytesRead,
                            NULL );

   // bail if read failed [error or client closed connection]
   if( !bReadOk || ulBytesRead == 0 )
    break;

   // all ok, process the message received

  }
 }
 else{
   // the client could not connect, so close the pipe. 
   CloseHandle( hPipe );
 }

 return 0;

Клиент:

HANDLE hPipe = INVALID_HANDLE_VALUE;

 // create the named pipe handle
 hPipe = CreateFile( L"\\\\.\\pipe\\nhsupspipe",
                     GENERIC_READ | GENERIC_WRITE,
                     0, 
                     NULL, 
                     OPEN_EXISTING,
                     0,
                     NULL );

 // if everything ok set mode to message mode
 if( INVALID_HANDLE_VALUE != hPipe ){
  DWORD dwMode = PIPE_READMODE_MESSAGE;
  // if this fails bail out
  if( !SetNamedPipeHandleState( hPipe, &dwMode, NULL, NULL ) ){
   CloseHandle( hPipe ); 

   return -1;
  }
 }

 unsigned long ulBytesWritten = 0;
 bool bWriteOk = WriteFile( hPipe, 
                            ( LPCVOID )&message, 
                            sizeof( Message ), 
                            &ulBytesWritten, 
                            NULL );

 // check if the writing was ok
 if( !bWriteOk || ulBytesWritten < sizeof( Message ) ){
  return -1;
 }

 // written ok

 return 0;

Упомянутое выше сообщение представляет собой структуру, которая будет вашим сообщением, которое вы, вероятно, захотите пакет.

Поскольку в вашем сценарии клиент (служба), вероятно, будет запущен и запущен раньше сервера (уведомителя), вам потребуется какая-то стратегия повторного подключения на стороне клиента.

И немного по-другому: вам следует внимательно рассмотреть то, что г-н Остерман сказал в своем ответе. (даже ни за что, кроме как за то, что он Ларри Остерман).

Вам необходимо использовать ReadFile или ReadFileEx (для перекрывающихся операций ввода-вывода) обычно на стороне уведомителя в потоке или цикле сообщений. Также просмотрите документацию для CreateNamedPipe и WaitNamedPipe.

В этом случае я бы, вероятно, использовал RPC вместо необработанных именованных каналов. С необработанными именованными каналами вы должны анализировать данные от клиента, что может привести к ошибкам безопасности. С помощью RPC вы можете позволить RPC анализировать данные за вас, что снижает вероятность появления ошибки.

Не совсем вопрос, но другой вариант - CreateEvent() и файл с отображением памяти.

Если бы я делал это, я бы заставил сервисную сторону выполнить CreateNamedPipe (исходящий), а затем вызвать ConnectNamedPipe, чтобы дождаться подключения уведомителя.

На стороне уведомителя я бы использовал CreateFile с FILE_FLAG_OVERLAPPED. При этом дескриптор канала будет сигнализироваться, когда данные станут доступны для чтения. Ваш уведомитель (предположительно) также будет поддерживать графический интерфейс, поэтому вы, вероятно, захотите, чтобы он вызывал MsgWaitForMultipleObjects в своем цикле событий. Это будет ожидать обработки сообщений или данных, поступающих в канал для обработки. Это будет работать почти как обычный цикл обработки событий, за исключением того, что его возвращаемое значение немного отличается от GetMessage() — он вернет WAIT_OBJECT_0, если ваш дескриптор получает сигнал, или WAIT_OBJECT_0 + 1, если у вас есть сообщение (при условии, что вы ожидаете только одно дескриптор -- на самом деле это WAIT_OBJECT_0 + N, где N – это количество дескрипторов, которые вы ждали). По большей части это похоже на обычный цикл PeekMessage или GetMessage — подождите, пока не будет что делать, сделайте это и снова подождите.