Multiple output pipes

[jacobbridges]

One input pipe to many output pipes. The data will be copied to all outputs.

Example:

# Some shell session
tail -f -n 1 data.csv | cutiepipe

# Another shell session
cutiepipe > data_copy1.csv

# Yet another shell session
cutiepipe > data_copy2.csv

[Blastus]

How this is implemented is up to you. There are numerous design decisions one could take is getting this to work:

• You could have a central server that is designed to process these kinds of request. Currently, there is the messy detail of what happens if there are multiple senders that start and a single receiver becomes active. As implemented in QTpipe, the senders and receivers do not care who is server or client, so the two senders would connect and be unable to do anything.
• It seems like it would be simpler to have one program (cutiepipe) to handle this awkward situation without further help from another program. However, there are some issues that you need to think through:
  • How does the sender know that there will be more than one receiver?
  • How many receivers is it supposed to support?
  • Can there be only between one and two receivers?
  • How long is a second or more receiver allowed to take before connecting to the sender?
  • Is a second receiver allowed to connect after the sender has already started sending data to the first receiver?
  • Should the sender wait around for a while after sending all data to the first receiver so that it can allow other receivers to connect and receive the same data?
  • How much data should the sender buffer to account for different positions it might be in its data stream while sending to more than one receiver?
  • Should that data be buffered to memory, a temporary file, or a database?
  • Are pauses in the data stream important?
  • Do these pauses need to be recorded in the buffer so that the timing may be replicated to all receivers?
  • Should these pauses be replicated on the sender side or the receiver side?

If you are to add this functionality, it would probably be best to implement named pipes first. Then you could create a policy that receivers must be run first naming the pipe they wish to receive data on, and then the sender with the same named pipe must be run. Receivers that are started after the sender will not receive the sender's data. This gets around the problem of buffering data and timings.