hiho@ll

this is very simple, but i don't really know the solution

i'm sure everybody knows the example
many processes have pipes to a server and give the server a command, which is executed by the server

that's easy:
open a pipe
make child's using fork();
and now the child sends a command using the pipe and the server receives it

how does the oposite way work?
i open a pipe
fork(); some childs
a child (everytime it's the same child who does this) then sends a command
and many other childs receive it!

the problem i have
if one forked() child receives the message
no other child receives it, because it's already read by the other child

it's like:
the first child who get's notified (by the select(); method) and reads the data
deletes the data so no other child can read it
well this makes sense: how do you know if the data in the pipe should be deleted for the next command which should be sent?
BUT that's a problem for me

i need a pipe where i can notifie many childs at the same time
anybody knows such a pipe? or another way i can send messages or commands (the size is variable) to my childs other than a socket server (because it's slow)?
hmm
maybe i have to use a AF_UNIX udp broadcast
but then i have to do message synchronization so they are received in right order

thx@ll

Can you clarify your terminology? I don't know whether you're talking about interprocess communication on a single machine, or whether you're talking about network communication from multiple machines? I also can't tell whether you're talking about pipes (I/O streams between processes on the same machine) or sockets (network I/O streams). You're mixing design and implementation as well. Use high level concepts, please. (IE: You have a task that listens for connections. When it hears a new connection request, it creates a new task to handle the new connection. That's a design. The implementation would be a process that listens and then fork()'s a child handler when a new request is heard.)

The way I see it, you want to build a distributed network of peers. In that case, you have a few different approaches:

#1 - UDP broadcast signaling messages. These messages can signal some site B to do something for or related to A, and then have B create a socket back to site A.

#2 - Have a shared list of peers. This can sent via broadcast, or via central server. The systems on this list will connect to each other, so that all machines are connected to all other machines.

#3 - Have a mix mode, where there are peers which connect to an ultra peer. These will be called peer groups. Then be able to connect peer groups via ultra peer grouping.

1. yes, i'm mixing the terminology because i didn't find a IPC method which can do what i want, so i think there isn't one
2. i'm mixing design and implementation
because i just wanted to describe what i need (design) and asked for the implementation

well, it was my fault if i didn't clarify myself good enough

here another explanation:
1. my problem is only on localhost! no other IP's no other CPU's
just one server
2. i need a "one-to-many" IPC solution

the only thing that seems to work for one-to-many is udp broadcasts
that's why i was talking about this
because i can also do a localhost udp broadcast
one process sends "Hello, i'm process 1" using udp broadcast and many processes answer "hello, i'm process2","hello i'm process 3", "hello i'm process 4"

why i was talking about pipes:
i tried this with pipes, but i only got a one-to-one IPC
the first process who got the message answered
and this could be process 2 or process 4
it depends on which process got the cpu

why pipes?
because i think they are faster and more flexible (than udp broadcast) and i only need a solution for localhost

just to answer your question, here is the design (simplified):
one task listens (a server)
other tasks need to know what the server got --> server has to send information at the same time to many processes
why at the same time? because the server doesn't know who is listening/who want's to know

the approaches you claimed are possible for my problem
but see it this way:
i'm asking here because maybe there is a better, faster and flexible way which i don't know

IPC doesn't allow you to have multiple listeners get the same message. However, you can have multiple processes listening on the same queue. You can send the same message with a different message type. Have it so that there is a base message type 0 for the pilot. Make your new programs write a message saying "I'm here" basically. The master program will then write a reply saying "You get message type (X)" The new program will then only listen for messages of the chosen "type." Hence, you can get the same message to multiple clients.

man msgrcv, and msgsnd. msgbuf->mtype is the field I'm talking about.

hmm
then i do the message queue implementation later

thx!