2

I'm creating a process that is going to publish data via a named pipe and I envision there being multiple subscribers. Is there some way my process can Tee off the named pipe it is wring too each time a new subscriber attempts to open the pipe?

Edit for Clarity I am trying use a broadcast model.

  • I'll make no distinction if there are 1 or N subscribers.
  • I do care if there are no subscribers. If no one is listening I'll turn part of the system off.
  • I don't care about addressing the data. As soon as someone subscribes I want them to get the complete set of data.
  • Subscribers shouldn't get any old data. As soon as they open the pipe they should be seeing new data like a stream.
Nick
  • 143
  • I'm not sure exactly what you have in mind, but I believe inotifywait can help you. – msb Mar 10 '21 at 19:29
  • @msb I'm not sure I understand what you're proposing with inotifywait. That I create a file that I always append to and other processes uses inotifywait to pend on that? – Nick Mar 10 '21 at 20:17
  • 1
    Does this answer your question? Can FIFO or other thing not block on writer's access, and instead just drop data? – Kamil Maciorowski Mar 10 '21 at 22:14
  • @KamilMaciorowski that is pretty similar to my application. UDP broadcast sockets are actually partly what inspired me to ask this. But with UDP you don't know if anyone is listening, and I'd rather not have to route all of my data through a UDP socket to accomplish what I'm after. I think it would be more straight forward to just create a new pipe every time a peer opens one, and destroy pipes when they're closed so that there is always one open socket waiting for a connection like a TCP server. But I don't want to reinvent the wheel if there is a built in way to do this. – Nick Mar 10 '21 at 22:53
  • @nick I thought you were already "always appending to" your named pipe. Like xhienne, I also didn't understand what you meant by 'tee off'. Sorry, I misunderstood what you were trying to do, I no longer think inotifywait can help you much. :( – msb Mar 11 '21 at 18:22

1 Answers1

4

First, the question in title:

Can multiple processes open a named pipe?

The answer is yes. I mean, more than one reader and more than one writer simultaneously.

Now your actual question:

Is there some way my process can Tee off the named pipe it is writing too each time a new subscriber attempts to open the pipe?

I'm not sure what you mean by "tee off" but here is a general answer:

  • Because opening the pipe for writing is a blocking operation, until someone else opens it for reading, and because writing to a pipe with no reader triggers a SIGPIPE, your writer (the publisher) can know for sure that there is at least one reader (subscriber).
    On the other hand, the writer cannot know whether there are multiple readers at a given time (you can mitigate this by spying the fifo activity with inotify, though)
  • The messages the publisher will send cannot be aimed at a specific reader.
  • The content of the message that the publisher writes won't be duplicated among readers (i.e. each reader gets the same message the writer sent). Instead, each reader will read a part of it. For example, if you write "HELLO WORLD" into a pipe with three subscribers (readers), then the first one may receive "HELL", the second one "LORD" and the last one "O W"

[edit] Now that you have clarified your question, what I have written above still applies and we can come to a conclusion: named pipes are clearly not the right tool for your needs. You probably need broadcast/multicast UDP sockets, or a dedicated messaging system like D-Bus, AMQP brokers, etc.

xhienne
  • 17,793
  • 2
  • 53
  • 69