У меня, похоже, есть проблема с именованными каналами 101. У меня очень простая настройка для подключения симплексного именованного канала, передающего данные из неуправляемого приложения C ++ в приложение, управляемое C #. Канал подключается, но я не могу отправить «сообщение» через канал, пока не закрою дескриптор, который, по-видимому, очищает буфер и пропускает сообщение. Это как сообщение заблокировано. Я попытался поменять роли клиент / сервер и вызывать их с различными комбинациями флагов без какой-либо удачи. Я могу легко отправлять сообщения в другом направлении из C # управляемых в C ++ неуправляемых. Есть ли у кого-нибудь понимание. Кто-нибудь из вас, ребята, может успешно отправлять сообщения из C ++ неуправляемым в C # управляемый? Я могу найти множество примеров внутриабонентских или неуправляемых каналов, но не управляемых / неуправляемых - просто заявляет, что может это сделать.
В списках для большей ясности я опустил большую часть материала обёртки. Ключевыми битами, которые я считаю важными, являются методы соединения / создания / чтения и записи канала. Не беспокойтесь о блокировке / потоке здесь.
C # Серверная сторона
// This runs in its own thread and so it is OK to block
private void ConnectToClient()
{
// This server will listen to the sending client
if (m_InPipeStream == null)
{
m_InPipeStream =
new NamedPipeServerStream("TestPipe", PipeDirection.In, 1);
}
// Wait for client to connect to our server
m_InPipeStream.WaitForConnection();
// Verify client is running
if (!m_InPipeStream.IsConnected)
{
return;
}
// Start listening for messages on the client stream
if (m_InPipeStream != null && m_InPipeStream.CanRead)
{
ReadThread = new Thread(new ParameterizedThreadStart(Read));
ReadThread.Start(m_InPipeStream);
}
}
// This runs in its own thread and so it is OK to block
private void Read(object serverObj)
{
NamedPipeServerStream pipeStream = (NamedPipeServerStream)serverObj;
using (StreamReader sr = new StreamReader(pipeStream))
{
while (true)
{
string buffer = "" ;
try
{
// Blocks here until the handle is closed by the client-side!!
buffer = sr.ReadLine(); // <<<<<<<<<<<<<< Sticks here
}
catch
{
// Read error
break;
}
// Client has disconnected?
if (buffer == null || buffer.Length == 0)
break;
// Fire message received event if message is non-empty
if (MessageReceived != null && buffer != "")
{
MessageReceived(buffer);
}
}
}
}
C ++ на стороне клиента
// Static - running in its own thread.
DWORD CNamedPipe::ListenForServer(LPVOID arg)
{
// The calling app (this) is passed as the parameter
CNamedPipe* app = (CNamedPipe*)arg;
// Out-Pipe: connect as a client to a waiting server
app->m_hOutPipeHandle =
CreateFile("\\\\.\\pipe\\TestPipe",
GENERIC_WRITE,
0,
NULL,
OPEN_EXISTING,
FILE_ATTRIBUTE_NORMAL,
NULL);
// Could not create handle
if (app->m_hInPipeHandle == NULL ||
app->m_hInPipeHandle == INVALID_HANDLE_VALUE)
{
return 1;
}
return 0;
}
// Sends a message to the server
BOOL CNamedPipe::SendMessage(CString message)
{
DWORD dwSent;
if (m_hOutPipeHandle == NULL ||
m_hOutPipeHandle == INVALID_HANDLE_VALUE)
{
return FALSE;
}
else
{
BOOL bOK =
WriteFile(m_hOutPipeHandle,
message, message.GetLength()+1, &dwSent, NULL);
//FlushFileBuffers(m_hOutPipeHandle); // <<<<<<< Tried this
return (!bOK || (message.GetLength()+1) != dwSent) ? FALSE : TRUE;
}
}
// Somewhere in the Windows C++/MFC code...
...
// This write is non-blocking. It just passes through having loaded the pipe.
m_pNamedPipe->SendMessage("Hi de hi");
...