双工命名管道在某个写入时挂起

Question

我有一个 C++ 管道服务器应用程序和一个 C# 管道客户端应用程序通过 Windows 命名管道进行通信（双工、消息模式、在单独的读取线程中等待/阻塞）。

一切正常（通过管道发送和接收数据），直到我尝试从客户端写入管道以响应表单“textchanged”事件。当我这样做时，客户端挂起管道写入调用（如果自动刷新关闭，则挂起刷新调用）。闯入服务器应用程序会发现它也在等待管道 ReadFile 调用并且没有返回。 我尝试在另一个线程上运行客户端写入——结果相同。

怀疑存在某种死锁或竞争条件，但看不到在哪里......不要认为我正在同时写入管道。

Update1：​​尝试以字节模式而不是消息模式进行管道 - 相同的锁定。

Update2：奇怪的是，如果（且仅当）我将大量数据从服务器泵送到客户端，它就可以解决锁定问题！？

服务器代码：

DWORD ReadMsg(char* aBuff, int aBuffLen, int& aBytesRead)
{
    DWORD byteCount;
    if (ReadFile(mPipe, aBuff, aBuffLen, &byteCount, NULL))
    {
        aBytesRead = (int)byteCount;
        aBuff[byteCount] = 0;
        return ERROR_SUCCESS;
    }

    return GetLastError();  
}

DWORD SendMsg(const char* aBuff, unsigned int aBuffLen)
{
    DWORD byteCount;
    if (WriteFile(mPipe, aBuff, aBuffLen, &byteCount, NULL))
    {
        return ERROR_SUCCESS;
    }

    mClientConnected = false;
    return GetLastError();  
}

DWORD CommsThread()
{
    while (1)
    {
        std::string fullPipeName = std::string("\\\\.\\pipe\\") + mPipeName;
        mPipe = CreateNamedPipeA(fullPipeName.c_str(),
                                PIPE_ACCESS_DUPLEX,
                                PIPE_TYPE_MESSAGE | PIPE_READMODE_MESSAGE | PIPE_WAIT,
                                PIPE_UNLIMITED_INSTANCES,
                                KTxBuffSize, // output buffer size
                                KRxBuffSize, // input buffer size
                                5000, // client time-out ms
                                NULL); // no security attribute 

        if (mPipe == INVALID_HANDLE_VALUE)
            return 1;

        mClientConnected = ConnectNamedPipe(mPipe, NULL) ? TRUE : (GetLastError() == ERROR_PIPE_CONNECTED);
        if (!mClientConnected)
            return 1;

        char rxBuff[KRxBuffSize+1];
        DWORD error=0;
        while (mClientConnected)
        {
            Sleep(1);

            int bytesRead = 0;
            error = ReadMsg(rxBuff, KRxBuffSize, bytesRead);
            if (error == ERROR_SUCCESS)
            {
                rxBuff[bytesRead] = 0;  // terminate string.
                if (mMsgCallback && bytesRead>0)
                    mMsgCallback(rxBuff, bytesRead, mCallbackContext);
            }
            else
            {
                mClientConnected = false;
            }
        }

        Close();
        Sleep(1000);
    }

    return 0;
}

客户端代码：

public void Start(string aPipeName)
{
    mPipeName = aPipeName;

    mPipeStream = new NamedPipeClientStream(".", mPipeName, PipeDirection.InOut, PipeOptions.None);

    Console.Write("Attempting to connect to pipe...");
    mPipeStream.Connect();
    Console.WriteLine("Connected to pipe '{0}' ({1} server instances open)", mPipeName, mPipeStream.NumberOfServerInstances);

    mPipeStream.ReadMode = PipeTransmissionMode.Message;
    mPipeWriter = new StreamWriter(mPipeStream);
    mPipeWriter.AutoFlush = true;

    mReadThread = new Thread(new ThreadStart(ReadThread));
    mReadThread.IsBackground = true;
    mReadThread.Start();

    if (mConnectionEventCallback != null)
    {
        mConnectionEventCallback(true);
    }
}

private void ReadThread()
{
    byte[] buffer = new byte[1024 * 400];

    while (true)
    {
        int len = 0;
        do
        {
            len += mPipeStream.Read(buffer, len, buffer.Length);
        } while (len>0 && !mPipeStream.IsMessageComplete);

        if (len==0)
        {
            OnPipeBroken();
            return;
        }

        if (mMessageCallback != null)
        {
            mMessageCallback(buffer, len);
        }

        Thread.Sleep(1);
    }
}

public void Write(string aMsg)
{
    try
    {
        mPipeWriter.Write(aMsg);
        mPipeWriter.Flush();
    }
    catch (Exception)
    {
        OnPipeBroken();
    }
}

Answer 1

如果您使用单独的线程，您将无法在写入管道的同时从管道中读取数据。例如，如果您正在从管道进行阻塞读取，然后进行后续的阻塞写入（来自不同的线程），则写入调用将等待/阻塞，直到读取调用完成，并且在许多情况下，如果这是意外行为，您的程序将陷入僵局。

我尚未测试重叠 I/O，但它可能能够解决此问题。但是，如果您决定使用同步调用，那么下面的模型可能会帮助您解决问题。

主/从

您可以实现一个主/从模型，其中客户端或服务器是主设备，另一端仅响应，这通常是您在 MSDN 示例中找到的内容。

在某些情况下，如果从站需要定期向主站发送数据，您可能会发现这个问题。您必须使用外部信号机制（管道外部）或让主设备定期查询/轮询从设备，或者您可以交换角色，其中客户端是主设备，服务器是从设备。

写入器/读取器

您可以使用写入器/读取器模型，其中使用两个不同的管道。但是，如果您有多个客户端，则必须以某种方式关联这两个管道，因为每个管道将具有不同的句柄。您可以通过让客户端在连接到每个管道时发送唯一标识符值来实现此目的，然后服务器将这两个管道关联起来。该数字可以是当前系统时间，甚至可以是全局或本地的唯一标识符。

线程

如果您决定使用同步 API，并且不想在从机端等待消息时被阻塞，则可以使用具有主/从模型的线程。然而，您将希望在阅读器读取消息（或遇到一系列消息的结尾）后锁定阅读器，然后写入响应（正如从机应该的那样），最后解锁阅读器。您可以使用使线程进入睡眠状态的锁定机制来锁定和解锁读取器，因为这将是最有效的。

TCP的安全问题

使用TCP而不是命名管道带来的损失也是最大的可能问题。 TCP 流本身不包含任何安全性。因此，如果安全是一个问题，您将必须实现这一点，并且您有可能创建安全漏洞，因为您必须自己处理身份验证。如果正确设置参数，命名管道可以提供安全性。另外，需要再次更清楚地说明：安全性并不是一件简单的事情，通常您会希望使用旨在提供安全性的现有设施。

Answer 2

我认为您可能会遇到命名管道消息模式的问题。在这种模式下，每次写入内核管道句柄都会构成一条消息。这不一定与您的应用程序所认为的消息相对应，并且消息可能比您的读取缓冲区大。

这意味着您的管道读取代码需要两个循环，内部读取直到完全接收到当前的[命名管道]消息，以及外部循环直到接收到您的[应用程序级别]消息。

您的 C# 客户端代码确实有一个正确的内部循环，如果 IsMessageComplete 为 false，则再次读取：

do
{
    len += mPipeStream.Read(buffer, len, buffer.Length);
} while (len>0 && !mPipeStream.IsMessageComplete);

您的 C++ 服务器代码没有这样的循环 - Win32 API 级别的等效内容是测试返回代码错误_更多_数据。

我的猜测是，这会导致客户端等待服务器在一个管道实例上读取，而服务器正在等待客户端在另一个管道实例上写入。

Answer 3

在我看来，你想做的事情不会按预期进行。
前段时间我试图做一些看起来像你的代码并得到类似结果的事情，管道刚刚挂起
而且很难确定到底出了什么问题。

我宁愿建议以非常简单的方式使用客户端：

1. CreateFile
2. 写请求
3. 读取答案
4. 关闭管道。

如果您想与客户端进行两种方式的通信，并且也能够从服务器接收未请求的数据，您应该
而是实施两个服务器。这是我使用的解决方法： 在这里您可以找到来源。