How reliable is the netnamedpipebinding infinite receiveTimeout?

I have a duplex WCF service that relies on a consistent named pipe connection between the service and the client. It's sort of a publish/subscribe system where the client calls Subscribe on the service and gets put in a subscription list. Then, the service calls certain update methods of its own, which will push the update to the client(s) via callbacks.

I've set the recieveTimeout for the netnamedpipebinding to "infinite." Can I reasonably rely on this connection to be open forever? More importantly, are there situations where the channel will fault outside of timeouts?

Since a named pipe is just a shared memory location, I can't think of many reasons why it would fail consistently besides hardware problems. Furthermore, there isn't much of a way of guaranteeing the connection outside of pinging at a certain interval.

On a side note, my gut feel is to avoid also making the client a WCF service. I know it's not a real cir开发者_C百科cular dependency, but it just feels icky. However, I'm open to people telling me I'm just being paranoid and that that kind of pattern is a-okay.

---

You can never rely on the connection. Single unhandled exception / fault on the service will close the channel. I think you should handle Closed and Faulted events on client or implement pinging mechanism with proxy recreation and resubscribtion.

When using duplex communication you simply need the client to expose contract - it is not the same as exposing the service because client do not expose an endpoint. The communication is performed by single channel created from client to service because Named pipes are duplex by design. Every time you will want to have duplex communication over some transport you will need some handling code on the client.