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]
# 1

Since Multicast is 'fire and forget' your approach will have problems. Use TCP rather than UDP then you can control who does what.

sabre150a at 2007-7-28 19:59:15 > top of Java-index,Core,Core APIs...
# 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

nichelea at 2007-7-28 19:59:15 > top of Java-index,Core,Core APIs...
# 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.

sabre150a at 2007-7-28 19:59:15 > top of Java-index,Core,Core APIs...
# 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 > top of Java-index,Core,Core APIs...