Multicast issue
Hi All,
I would like to know some idea to resolve this issue about UDP in a easy way (if it exists)....
Basically I have a process that publishes some UDP multicast packages and many process that read such packages. Every packages represent a request for a "work" and I would that just one "reader" performs the work.
Thanks
Ste
[359 byte] By [
nichelea] at [2007-11-27 10:43:16]

# 2
I know, UDP is not reliable, but don't matter about that because this is not important in my case.
The point is I don't know the receiver of my published message (read request for a "work"). It's something like a queue of works where a work is published multicast and more workers receive the works (multicast!!) but a work must be done just by a worker.
Ste
# 3
> I know, UDP is not reliable, but don't matter about
> that because this is not important in my case.
I did not comment on the reliability - only on the 'fire and forget' aspect.
> The point is I don't know the receiver of my
> published message (read request for a "work").
You can never know unless you create a protocol to handle this. Something like
To everybody - I have a task to perform, who can do it.
From those that can do it - I can do it.
To everybody - 'fred' is going to be doing this task.
From 'fred' - ok, I will do it
If no ok response from 'fred' within some timeout - are you there 'fred'
and so on
> It's
> something like a queue of works where a work is
> published multicast and more workers receive the
> works (multicast!!) but a work must be done just by
> a worker.
Using TCP gets rid of most of the complex protocol since it is built in to TCP.
# 4
> I know, UDP is not reliable, but don't matter about that because this is not important in my case.
If you must have exactly one worker executing each packet, reliability is certianly important. You either have to use a reliable protocol or you have to build one.
Can't your broadcaster be a TCP server that workers connect to? so it is the *server's* address that is known, not the workers'?
ejpa at 2007-7-28 19:59:15 >
