2

I'm writing a Windows Service that will be called from an application. The service advertises a named pipe, and I need to know whether it is customary (for the Service in this case) to test the pipe from time to time to know whether it's faulty, because the app can't tell the Service that the pipe is disconnected since the pipe itself is the method of communication between the app and the Service. Both are running on the same computer. (Are pipes like network connections, or are they more reliable.)

EDIT

The service is supposed to run all the time (from startup to shutdown, through logons, logoffs, sleep, etc.).

ispiro
  • 26,556
  • 38
  • 136
  • 291
  • We use them alot and find them very reliable. I've never found it necessary to send any kind of keep-alive messages. We usually keep the connection for hours at a time - until the user quits the software. (However, this is with C++ calling the Win32 API directly with overlapped I/O, so I can't comment on C#'s implementation.) – 001 Apr 10 '18 at 14:24
  • @JohnnyMopp Thanks. I now edited the question (somewhat related to your comment). – ispiro Apr 10 '18 at 14:37
  • If the pipe is down (due to a network fault, say) do you want to take any action immediately or within a given timespan? If so, this means changes to state of the channel are important to the application layer, therefore you need an application-layer keepalive to detect these changes. If not, not. – Ben Apr 10 '18 at 17:19
  • See also https://stackoverflow.com/questions/5338352/asyncsockets-and-silent-disconnections/5338459#5338459 – Ben Apr 10 '18 at 17:24
  • @Ben `(due to a network fault, say)` - As I wrote, `Both are running on the same computer.` - so that's not applicable. In fact, that's exactly my question - is it common with pipes as with networks. As for your second comment - that's on macOS, and as I wrote, `I'm writing a Windows Service`. As for your question - I do need to take action immediately if the pipe is down. The Service might be called at any time. – ispiro Apr 10 '18 at 17:54
  • It does't make a lot of sense to compare "pipes as with networks" in general. Named pipes are commonly used over the wire with a remote server. The SMB protocol has extensive support for this using the implicit IPC$ share. For example, see [Connecting to a Share by Using an SMB2 Negotiate](https://msdn.microsoft.com/en-us/library/cc246793.aspx) and [Executing an Operation on a Named Pipe](https://msdn.microsoft.com/en-us/library/cc246794.aspx). – Eryk Sun Apr 10 '18 at 20:54
  • @eryksun I stated `Both are running on the same computer.`. – ispiro Apr 10 '18 at 21:01
  • 1
    Named pipes use the the named pipe filesystem (NPFS), so your question amounts to asking about the reliability of a filesystem driver that's an integral component of the kernel. – Eryk Sun Apr 10 '18 at 21:09
  • @eryksun I'm not asking how well that code was written. I'm asking if that code tends to close pipes for "reasons" (resources getting low, timeout, simple limited time, etc.). – ispiro Apr 10 '18 at 21:14
  • 1
    AFAIK, there's no reason the named pipe filesystem would close the pipe instance instance as a matter of timeouts or "limited time". But I'll search for something along those lines. As to resources, the memory for the pipe is already allocated in the kernel. As a matter of reliability, I'm sure no filesystem just pulls the plug on data structures that have non-persistent state or metadata that hasn't been persisted. Under extreme memory pressure, some operations and allocating new instances may fail, but a system in such a state is in a critical failure. – Eryk Sun Apr 10 '18 at 21:41
  • You can **always** lose comms. It doesn't make any difference **why**, it can still happen and you still have to deal with it appropriately (whatever "appropriate" may be for you). On same computer, issues include: Service process may crash, client process may crash, service may be stopped or restarted by admin action. Advice: For same-computer comms use RPC or (easier) DCOM. Even Json over HTTP if you want, but a roll-your-own protocol is just asking for trouble. – Ben Apr 11 '18 at 08:31
  • @Ben Thanks. Do you have any pointers for doing these? (If by RPC you mean WCF - trying it in the past seemed riddled with gotchas and way more complicated than named pipes. Or am I missing something?) – ispiro Apr 11 '18 at 12:29
  • By RPC I mean RPC. That's what Windows uses for this purpose. https://msdn.microsoft.com/en-us/library/windows/desktop/aa378651(v=vs.85).aspx – Ben Apr 11 '18 at 12:49
  • @Ben Thanks. But I'll stick to C#. – ispiro Apr 11 '18 at 13:01

0 Answers0