anyone know of an easy way to take the stdout of a program and send it to a port, and to then be able to connect to that port from somewhere else and and give it as the stdout? I want to piece together a simple lan video stream, so i could use

cat film.avi | toport host 1234

and then

fromport host 1234 | mplayer -

netcat can do this, but i want to be able to conect to the port more than once (so a film will be playing synchronized in two locations. any idea.

Maybe Apache can serve it as well as any, tho IMO "sychronized" will be a problem, there's no way any consecutive viewer can receive hints from the system or the file served where the first hookup occurred...

well, shoutcast / icecast does the same thing with mp3's... must be an easy way. ahh well, it's just another thing stopping me working.

I think this is what you are looking for:

http://home.t-online.de/home/gerd.o/netpipe.html

404'd mik.

Hmmm the link on the page seems to point to jan.o instead of gerd.o

This link does work:
http://home.t-online.de/home/gerd.o/netpipe.tar.gz

I was looking for a simple tool which will multicast any data from stdin. This small program seems to do the trick but he's got a bit of an expensive protocol written around it. He expects the clients to acknowledge all the data. It will work but will cause a lot of extra network traffic. The problem with udp is that it can lose packets during high network activity. But with streaming of audio or video it's not a disaster if one packet is lost because the screen might just flicker for one frame and then it will continue on with the next. He's added the acknowledging to make sure the data gets received intact.
You wanted to do something like stream an avi file. Standard avi files aren't a streaming format so the movie will get messed up if you lose one packet. That's why tcp might be a better way, but the problem with tcp is that if you are using two clients it will have to send the data to both clients, which would double network traffic.
Now that I think about it you'll probably run into all kinds of other troubles. So I think your quick simple solution isn't really feasible, unless you like to waste bandwidth and processing power.

You might want to look into streaming video servers if you want a complete solution.