Named pipes - am I missing something silly?
in [Win32 Kernel]
|
Prev: Not getting message for keyboard delete button
Next: What is the protocol for GMT offset in SMTP (e-mail) header time-stamp?
From: Steve Rencontre on 1 Apr 2010 10:17 I have a client which sends messages to a server over a named pipe. If the server goes away, I want the client to detect this immediately without having to wait until it next has a message to send. I can't seem to find any suitable function or waitable object, which seems silly. IOW, I want to write code something like: wait for event switch (event) case MESSAGE_AVAIL write message to pipe case PIPE_BROKEN close local pipe handle ... I feel sure I must be missing something obvious, but can anyone tell me what? I guess I could make the pipe bidirectional and have an overlapped read waiting for data the server will never write, but I'm sure there ought to be something more elegant than that. Thanks.
From: Chris Becke on 1 Apr 2010 10:56 Whats silly? Named Pipes in this case are layered over TCP, which is not a noisy protocol - tcp doesn't send anything unless the application code has something to send. As such, there is no general way to detect a 'dead' server on a quiet connection. If there is an expectation that the server should be sending some kind of heartbeat to all clients, one could implement a read timeout. Otherwise, the only way to detect that a server has dropped off the internet is to try and send something, and respond to the error that results. On 01/04/2010 16:17, Steve Rencontre wrote: > I have a client which sends messages to a server over a named pipe. If > the server goes away, I want the client to detect this immediately > without having to wait until it next has a message to send. I can't seem > to find any suitable function or waitable object, which seems silly. > > IOW, I want to write code something like: > > wait for event > switch (event) > case MESSAGE_AVAIL > write message to pipe > case PIPE_BROKEN > close local pipe handle > ... > > I feel sure I must be missing something obvious, but can anyone tell me > what? I guess I could make the pipe bidirectional and have an overlapped > read waiting for data the server will never write, but I'm sure there > ought to be something more elegant than that. > > Thanks.
From: Steve Rencontre on 1 Apr 2010 11:31 On 01/04/10 15:56, Chris Becke wrote: > Whats silly? > Named Pipes in this case are layered over TCP, which is not a noisy > protocol - tcp doesn't send anything unless the application code has > something to send. Hmm, take your point, but it's not obvious from the SDK docs that it's such a thin layer. For some reason, I had it in my head that pipes had higher-level semantics than that. > As such, there is no general way to detect a 'dead' server on a quiet > connection. Ok, let me give some more background as to what I'm actually doing: The client is actually a relay, which forwards messages received on an SSL socket to the server which is another process on the same machine. If I shut down the server and then restart it, it's unable to recreate the named pipe because the client still has it open. What I need is a way for the client to spot that the server has gone away, close its end of the pipe and only try to re-open it next time it's needed. Alternatively, is there a way that the server can reconnect to the existing pipe? ISTM that CreateNamedPipe() will only open a new instance and CreateFile() will only open a client end. > If there is an expectation that the server should be sending some kind > of heartbeat to all clients, one could implement a read timeout. Of course I can do that, it just seems that there ought to be a more direct method. But perhaps there isn't... > Otherwise, the only way to detect that a server has dropped off the > internet is to try and send something, and respond to the error that > results. I didn't make it clear originally, but as I said, this isn't somewhere else on the Internet, it's another process on the same machine. It's certainly /possible/ for the pipe to know when it's broken without waiting for an attempt at sending traffic. Thanks for your response. If you've got any suggestions for a quicker solution than implementing some form of explicit link monitoring, I'd be grateful, but if not, at least I know that it wasn't me not seeing something that was staring me right in the face :-) > > On 01/04/2010 16:17, Steve Rencontre wrote: >> I have a client which sends messages to a server over a named pipe. If >> the server goes away, I want the client to detect this immediately >> without having to wait until it next has a message to send. I can't seem >> to find any suitable function or waitable object, which seems silly. >> >> IOW, I want to write code something like: >> >> wait for event >> switch (event) >> case MESSAGE_AVAIL >> write message to pipe >> case PIPE_BROKEN >> close local pipe handle >> ... >> >> I feel sure I must be missing something obvious, but can anyone tell me >> what? I guess I could make the pipe bidirectional and have an overlapped >> read waiting for data the server will never write, but I'm sure there >> ought to be something more elegant than that. >> >> Thanks. >
From: Steve Rencontre on 1 Apr 2010 12:57 Ah, got a solution now. I need to support XP so I can't use GetNamedPipeServerProcessId(), but that gave me the clue. When the server gets a client connection, it writes its process ID to the pipe. The client can then use that to get a waitable handle so that it can tell when the process has gone away, and for my purposes, that's good enough. Thanks for listening :-)
From: Paul Baker [MVP, Windows Desktop Experience] on 27 Apr 2010 20:37
Nice! So this would only work if the named pipe server was local :) I have a named pipe client that calls WriteFile in various threads and has one thread waiting on ReadFile. ReadFile fails as soon as the pipe server closes the pipe, even remotely. It must be sending something back to the client (I did not read the protocol specification). I discovered this by accident. I need to call ReadFile so I can both receive and send messages. You could call ReadFile for this purpose without expecting a message, but that seems like overkill (as you imply). Is that what you meant by a read timeout? Paul "Steve Rencontre" <spam(a)bit.bucket> wrote in message news:Oz4ijxb0KHA.3676(a)TK2MSFTNGP05.phx.gbl... > Ah, got a solution now. I need to support XP so I can't use > GetNamedPipeServerProcessId(), but that gave me the clue. When the > server gets a client connection, it writes its process ID to the pipe. > The client can then use that to get a waitable handle so that it can > tell when the process has gone away, and for my purposes, that's good > enough. > > Thanks for listening :-) |