-
-
Save pauldix/1081387 to your computer and use it in GitHub Desktop.
# here's the dealer socket in one process | |
require 'ffi-rzmq' | |
@context = ZMQ::Context.new(1) | |
@sock = @context.socket(ZMQ::XREQ) | |
@sock.bind("tcp://*:5550") | |
count = 0 | |
while true do | |
count += 1 | |
puts count | |
@sock.send_string("#{count} messge", 0) | |
sleep 1 | |
end | |
# and here's the REP socket in another process | |
require 'ffi-rzmq' | |
@context = ZMQ::Context.new(1) | |
@socket = @context.socket(ZMQ::REP) | |
@socket.connect("tcp://localhost:5550") | |
while true do | |
puts "attempting recv_string" | |
puts @socket.recv_string | |
end | |
# and the output on the Dealer side: | |
# 1 | |
# 2 | |
# 3 | |
# ... | |
# and on the REP side: | |
# attempting recv_string | |
# then nothing else. the dealer keeps going, but the REP is just stuck. If I don't start the REP then the | |
# dealer just waits after the first message. |
oh thank god. I knew about the requirement for having the REP do a send. I just didn't bother to put that in because it never got past the first receive. The example in the guide needs to be updated since it doesn't have that first send on the XREQ socket.
Finally, why would I have the REP be the one to bind? My use case is that the XREQ is part of a queue broker. Only one of them and many REP workers to process stuff.
Like I said, it's good practice to have the receiver(s) up and running first.
For a setup similar to the one you describe, I always put a QUEUE device in between the producer and consumer. I find it easier to manage having each producer (and each consumer) connect to a single address (the device). The way you describe your setup, each producer would have to know the address of every consumer; I find that to be more fragile in my environment, so I use devices to simplify the topology.
Either way will work. 0mq gives you lots of flexibility.
A REP socket enforces a very strict recv/send/recv/send pattern. Your code for the REP socket only ever does a recv. The second time you attempt to recv (without an intervening send) and it will fail. The DEALER socket doesn't have this issue; there is no state machine enforcing that pattern.
Here is some working code. Note that I also switched around which socket does a bind and which does a connect. It's good practice to have the receiver up and running first.
I should have seen the solution sooner. Time for bed!