[zeromq-dev] 0MQ/2.0 - alpha version available

Martin Sustrik sustrik at fastmq.com
Mon Sep 14 13:04:47 CEST 2009


Hi Aamir,

Find my comments inlined:

> 1a. WIll the load-balancing exchange functionality be preserved in 0MQ 2.0? 
> 
> Personally I would like to be able to specify a list of IP addresses to 
> which messages are sent in round-robin fashion. This way we can send 
> load-balanced messages without the receivers having to know the IP 
> address of the sender. When sending a load-balanced message it  would 
> also be quite useful to know which IP address the 0MQ load-balancer is 
> sending the message to.

Yes. Load balancing is on the roadmap. First we'll get pub/sub into 
shape, then we'll add load-balancing capabilities. As for IP address 
issue see below.

> 1b. If load-balancing is supported, how would it work with the new 
> bidirectional messaging feature?

It's meant for request/reply scenarios. The requester application sends 
requests to services (load-balancing the requests) and receives the 
replies. Bidirectional communication means that there's only one TCP 
connection between the requester and the service. With 0MQ/1.0 you had 
to have 2 connections, one to send request, other one to receive replies.

> 2. Will the bidirectional request reply mechanism be assynchronous?  Or 
> will it be similar to RPC (remote procedure call)?

I would like to support both use cases. The RPC-like one is pretty 
straightforward. Suggestions for how the async version should work are 
welcome.

> 3. When receiving a message, will it be possible to know which IP 
> address the message originated from?
> 
> 5. In the event that a connection is disconnected, will it be possible 
> to see the IP address which caused the error? 

IP address is not part of a message. One of the goal of the messaging 
layer is to shield the user from the underlying networking 
infrastructure. Of course, you have to supply IP addresses when 
establishing the wiring, however, once the thing is up and running, 
actual network layout should be irrelevant to the applications.

The answer to your question depends on what you are trying to achieve. 
Is it identifying the application that sent the message? If so, the name 
of the application should be made part of the message. That way your 
code will continue to work even if physical location (IP address) of the 
app is changed. If what you need is to know who to send the reply to in 
request/reply scenario, 0MQ should handle that for you and you shouldn't 
care. Etc.

 > 4. Suppose that I do not know in advance which IP address a message
 > needs to be sent to. In other words, the destination IP address is a
 > feature of the message itself. Would the correct way be to connect a
 > socket to the IP address, send a message and then disconnect the socket?
 > Would the repeated connecting and disconnecting create a significant
 > overhead?

AFAIU that's pub/sub scenario. Receiving applications subscribe for 
messages with specific tag (called "topic"). Publisher tags each message 
with the topic. Pub/sub kind of works already. You may play with it 
later on this week when alpha2 is released.

No connecting/disconnecting is involved, so the whole thing is pretty 
efficient.

> 6. Will 0MQ 2.0 support process-scope messaging as 0MQ 1.0 does? If so, 
> how will symbolic name resolution work in this case (presumably it would 
> not depend on network IP addresses or DNS hostnames)? 

Yes. We're moving the functionality from 1.0 to 2.0 gradually, so it'll 
take some time (not long) to get it into 2.0.

In-process messaging will appear to be just another protocol available 
(aside of TCP and PGM):

zmq_bind (s, "inproc://myendpoint");
...
zmq_connect (s, "inproc://myendpoint");

HTH.
Martin



More information about the zeromq-dev mailing list