Can a named-pipe client write to multiple instances?

After creating multiple instances of a named pipe (using CreateNamedPipe()), I use CreateFile() to form a pipe client.

When the client writes a message to the pipe, only one server instance gets it.

Is the开发者_运维百科re a way for the client to write a message to all instances?

When a client connects to an instance of a named pipe, the manner in which the operating system chooses which server instance to make the connection to is undocumented, as far as I know. However, empirically it appears to be done on a round robin basis.

If you are prepared to rely on undocumented behaviour which may change with service packs and QFE patches, your client can keep closing its pipe handle and calling CreateFile again to get a new one - each time it will attach to a new server instance of the pipe. However, there is a problem with this in that the client would not know when to stop. I suppose you could invent some mechanism involving a response from the server to break the loop but it is far from satisfactory. This isn't what named pipes were designed for.

The real purpose of multiple server instances of a pipe is to enable pipe servers to handle multiple clients concurrently. Usually, the same server process manages all the instances.

You really want to turn things around: what you think of as your client should be the server, and should create and manage the pipe. Processes which want notification would then connect as clients of the named pipe. This is a pattern which can be implemented quite easily using WCF, with a duplex contract and the NetNamedPipeBinding, if that's an option.

No, a pipe has two ends. Loop through the pipes. A mailslot supports broadcasts but delivery isn't guarantee.