I've got a C++ program that is creating a named pipe to write data to. Some customers have reported a situation where the client connects to the named pipe but the server end fails to write the data (with ERROR_NO_DATA
).
This error code isn't really explained in any MSDN page that I could find; does anyone have any ideas on how to fix this? Or what the cause is?
ostringstream pipeName;
pipeName << "\\\\.\\pipe\\unique-named-pipe-" << GetCurrentProcessId();
pipeHandle = CreateNamedPipeA(
pipeName.str().c_str(), // pipe name
PIPE_ACCESS_DUPLEX, // open mode
PIPE_TYPE_BYTE | PIPE_READMODE_BYTE, // pipe mode
PIPE_UNLIMITED_INSTANCES, // max instances
512, // output buffer size
512, // input buffer size
0, // use default timeouts
NULL); // security attributes
if (INVALID_HANDLE_VALUE == pipeHandle)
{
THROW("Failed to create named pipe", GetLastError());
}
cout << "Pipe ready" << endl;
// Wait for a client to connect to the pipe
BOOL status = ConnectNamedPipe(pipeHandle, NULL);
if (!status)
{
DWORD lastError = GetLastError();
if (ERROR_PIPE_CONNECTED != lastError)
{
THROW("Failed to wait for client to open pipe", lastError);
}
else
{
// Ignore, see MSDN docs for ConnectNamedPipe() for details.
}
}
// response is a std::string
int writeOffset = 0;
int length = response.length();
while ((int) response.length() > writeOffset)
{
DWORD bytesWritten;
BOOL status = WriteFile(
pipeHandle,
response.c_str() + writeOffset,
length - writeOffset,
&bytesWritten,
NULL);
if (!status)
{
// This sometimes fails with ERROR_NO_DATA, why??
THROW("Failed to send via named pipe", GetLastError());
}
writeOffset += bytesWritten;
}
#define THROW(message, errorCode) \
{ \
fprintf(stderr, "%s: line: %d file: %s error:0x%x\n", \
message, __LINE__, __FILE__, errorCode); \
fflush(stderr); \
throw message; \
} \
Thanks!
Looking at WinError.h, which is where this and other error codes are defined:
//
// MessageId: ERROR_NO_DATA
//
// MessageText:
//
// The pipe is being closed.
//
#define ERROR_NO_DATA 232L
Sounds like the client has already closed their end of the pipe - perhaps the client code thinks it has already got the full string, closes their end, while the code above continues to try to write?
The technical post webpages of this site follow the CC BY-SA 4.0 protocol. If you need to reprint, please indicate the site URL or the original address.Any question please contact:yoyou2525@163.com.