How to detect a client disconnect using a named pipe client/server?
I'm learning about named pipes and was playing with the named pipe client and server examples from the MSDN doc:
I modified the client so I can type in messages to the console and have them sent to the server where it displays the message and sends back a reply. Essentially I added a loop which starts after the SetNamedPipeHandleState() call and ends before the CloseHandle() call (i.e. the open and close happen outside the loop, so I am using the same pipe handle within the loop).
My question is, if I kill the client (by closing it or ending it via Task Manager) is there any way for the server side to detect the disconnect?
I've tried using GetNamedPipeHandleState() hoping it return failure and a call to GetLastError() would return ERROR_PIPE_NOT_CONNECTED, but that was not the case. Because of the way this server is set up I had to do this in the CompletedReadRoutine function and create a "controlled" failure. What I did was, with a breakpoint on the CompletedReadRoutine in the server:
- started the server
- started the client
- sent a message via the client (hits the breakpoint in the server here)
- killed the client
- Stepped through to the GetNamedPipeHandleState
The call to GetNamedPipeHandleState() returns successfully so I never got to do the GetLastError() call. When it gets to the WriteFileEx call it fails and a call to GetLastError at that point returns an ERROR_NO_DATA.
Looking at the pipe functions I can't see anything else that would possibly help here. I am missing something or is a client disconnect just not detectable.
The only other thing I can think of is collecting the pid's of the connecting clients (via GetNamedPipeClientProcessId) and spinning off watchdog threads to check if they are still alive. Though, just thinking about doing that sets off my spidey sense.
Is there a way to detect disconnected clients when using named pipes?
Answer
Doesn't ReadFile() return and error and GetLastError() then return ERROR_BROKEN_PIPE?