[zeromq-dev] Publish / Subscribe vs Multicast

[gonzalo diethelm]

[AARGH! Again, sorry for previous empty message.]

> > 1. Why does sender try to send all messages to one receiver when
there
> > is no sleep between messages? Is it due to batching? My messages are
32
> > bytes long.
> 
> I suppose the problem is all the messages are sent immediately after
> first receiver connects. When the second one connects there are no
> messages remaining. 0MQ is very fast. If you wan to test in at full
> speed you should process messages in orders of millions rather than
> thousands.

This is correct. I was able to see the sender sending messages to both
receivers once I upped the number of messages to at least 100K.

> > 2. It seems after a message has been sent to one receiver, there is
no
> > retry; if the receiver stopped receiving messages, and there are
more
> > receivers willing to receive, they still don't get any messages.
Right?
> 
> Right. The flow control should be done by limiting number of messages
on
> the fly. That way if the receivers stops processing messages or is
> simply falling behind, limit is hit and messages are re-routed to
other
> receivers.
> 
> Unfortunately, this feature is not yet ported from 0MQ/1.0. It is
being
> worked on and will be available in couple of weeks time.

Ok. Can you explain what the interfaces for this will look like? As a
preview?

> > 3. It would be nice if zmq_sleep() took milliseconds instead of
seconds
> > as a parameter.
> 
> Yeah. It would be nice. However, I am not sure whether all the
platforms
> we are running on support usleep... to be investigated.

Linux and Windows do. What other platforms are supported currently?
Isn't the whole world running on Linux by now? ;-)

> > When I get back to the office, I will finish the butterfly tutorial.
> 
> !

I did finish it. It took me a while to understand the usage rules for
bind and connect. As Martin mentioned in a previous message:

> The endpoint that should handle multiple connections (server) should
bind,
> while the one that handles only a single connection (client) connects.

This rule works no matter if you are actively initiating a connection or
passively waiting for it; if you handle multiple connections, you MUST
bind.

Anyway, I have a working butterfly tutorial (which is rather small);
component1 and component2 where subsumed into a single component (since
they only differ in their endpoints), and I use zmq_streamer as the
intermediate component. I also have a bash script to launch the programs
in several combinations, to test how the message throughput varies as
predicted by theory (it does). If anybody is interested in me doing
something with it, please let me know.

One final note: working on this tutorial made me realize how easy and
powerful ZMQ is. I can now think about butterfly in the Java world, and
maybe come closer to my specific needs.

Thanks and best regards.

-- 
Gonzalo Diethelm



----------------------------------------- 
Declaración de confidencialidad: Este Mensaje esta destinado para
el uso de la o las personas o entidades a quien ha sido dirigido y
puede contener información reservada y confidencial que no puede
ser divulgada, difundida, ni aprovechada en forma alguna. El uso no
autorizado de la información contenida en este correo podrá ser
sancionado de conformidad con la ley chilena. 
Si usted ha recibido este correo electrónico por error, le pedimos
eliminarlo junto con los archivos adjuntos y avisar inmediatamente
al remitente, respondiendo este mensaje. 

"Before printing this e-mail think if is really necesary".
Disclosure: This Message is to be used by the individual,
individuals or entities that it is addressed to and may include
private and confidential information that may not be disclosed,
made public nor used in any way at all. Unauthorized use of the
information in this electronic mail message may be subject to the
penalties set forth by Chilean law. 
If you have received this electronic mail message in error, we ask
you to destroy the message and its attached file(s) and to
immediately notify the sender by answering this message.