Why wait for all receivers to connect?

[innerop]

If.I was sending an infinite "application/octet-stream" stream (e.g. from a webcam) and would like receivers to be able to connect at any point in time while the pipe is still open (imagine I allow it and can handle that in the receivers) what changes would be needed (which part of the code) in order to make it so that it does not wait for all receivers to connect before piping the content? Does it allow that already?

[nwtgck]

First, you need to use nwtgck/piping-server instead of this project piping-server-rust because piping-server-rust does not supported multiple receivers yet.

The reason for waiting all receivers is for achiving storageless and lossless transfer. For transferring the same conntent for all receivers without waits, the server needs to store data.

---

In some usecase, receivers can loss data. I have an experimental project, not Piping Server. It transfers without waiting receivers and never store data. Here is a demo. The top one is a sender. The others are all receivers.

http-cast.mp4

Here is how to run the experimental project.

# Run http-cast
git clone git@github.com:nwtgck/http-cast.git
cd http-cast/
npm ci
npm start

# sender
curl -sST- localhost:8080/mypath

# receiver
curl localhost:8080/mypath

[innerop]

Yes exactly! it becomes like a websocket chat server but one-to-many instead of many-to-many. It's very easy to do with websockets. You join as sender on a specific channel/topic, and others joining after you are the receivers. If receivers can tolerate loss of data (e.g. jumping in the middle of an HLS video stream, they simply wait for the next file segment to be transmitted before they start decoding) then this becomes a 1-to-many multi-cast tool.

Like I said, it's very easy to do with websockets. I'm just wondering about how you'd do it and if it would scale better and be lighter. :)

Thank you for engaging! Love the idea.