Split the code into two programs, one multi-client, one server, then remove setting ZMQ_IDENTITY, i.e. defaulting to UUID, then the client never sees a reply from the server,

--- lruqueue.c  2010-12-08 12:39:08.000000000 +0800
+++ client.c    2010-12-08 12:59:34.000000000 +0800
@@ -9,7 +9,7 @@
 static void *
 client_thread (void *context) {
     void *client = zmq_socket (context, ZMQ_REQ);
-    s_set_id (client);          //  Makes tracing easier
+//    s_set_id (client);          //  Makes tracing easier
     zmq_connect (client, "ipc://frontend");

     //  Send request, get reply

client:

client: zhelpers.h:45: s_recv: Assertion `zmq_recv (socket, &message, 0) == 0' failed.
Aborted

server:

Worker: HELLO
Worker: HELLO
Worker: HELLO
Worker: HELLO
Worker: HELLO
Worker: HELLO
Worker: HELLO
Worker: HELLO
Worker: HELLO
Worker: HELLO

"c" doesn't compile unless INCDIR is set - it puts a blank "-I" and then gcc eats the filename.

in the zmq guide in the lazy pirate pattern, why is it necessary to check the sequence for the response?

From the previous documentation my understanding was, that the req socket would have a unique identifier associated with it and thus get a new identity upon recreating it. If that were the case then I don't see how a response would be retrieved for a previous request on a different socket.? Now when an identity would have been set, that would be different , but that is not done in the example. Am I missing something here ?

This example doesn't appear to work as expected. On Ubuntu 10.10 it aborts,

Worker: HELLO
Worker: HELLO
Worker: HELLO
Client: OK
Worker: HELLO
Client: OK
Worker: HELLO
Client: OK
Worker: HELLO
Client: OK
Worker: HELLO
Client: OK
Worker: HELLO
Client: OK
Worker: HELLO
Client: OK
Worker: HELLO
Client: OK
Client: OK
Client: OK
lruqueue: zhelpers.h:45: s_recv: Assertion `zmq_recv (socket, &message, 0) == 0' failed.
Aborted

Have tried to run the clone server example v6 from the Zguide and getting some weird behavior that I wanted to check. I am attempting to run the C example with two clone servers and two clients. I start the primary clone server and it gives the following output:

MacBookPro:C matt$ clonesrv6 -p 12-02-08 11:28:22 I: primary master, waiting for backup (slave) 12-02-08 11:28:22 I: zloop: register SUB poller (0x7fb692403bb0, 0) 12-02-08 11:28:22 I: zloop: register timer delay=1000 times=0 12-02-08 11:28:22 I: zloop: register timer delay=1000 times=0 12-02-08 11:28:22 I: zloop: polling for 1000 msec 12-02-08 11:28:23 I: zloop: call timer handler 12-02-08 11:28:23 I: zloop: call timer handler 12-02-08 11:28:23 I: zloop: call timer handler 12-02-08 11:28:23 I: zloop: polling for 1000 msec 12-02-08 11:28:24 I: zloop: call timer handler 12-02-08 11:28:24 I: zloop: call timer handler 12-02-08 11:28:24 I: zloop: call timer handler 12-02-08 11:28:24 I: zloop: polling for 999 msec

I then start the second clone server and it gives the following:

MacBookPro:C matt$ clonesrv6 -b 12-02-08 11:29:01 I: backup slave, waiting for primary (master) 12-02-08 11:29:01 I: zloop: register SUB poller (0x7fbf5bc03b90, 0) 12-02-08 11:29:01 I: zloop: register timer delay=1000 times=0 12-02-08 11:29:01 I: zloop: register timer delay=1000 times=0 12-02-08 11:29:01 I: zloop: polling for 1000 msec 12-02-08 11:29:01 I: zloop: call SUB socket handler (0x7fbf5bd012a0, 0) 12-02-08 11:29:01 I: zloop: polling for 398 msec 12-02-08 11:29:02 I: zloop: call timer handler 12-02-08 11:29:02 I: zloop: call timer handler 12-02-08 11:29:02 I: zloop: call timer handler 12-02-08 11:29:02 I: zloop: polling for 1000 msec 12-02-08 11:29:02 I: zloop: call SUB socket handler (0x7fbf5bd012a0, 0) 12-02-08 11:29:02 I: connected to primary (master), ready as slave 12-02-08 11:29:02 I: zloop: register SUB poller (0x7fbf5bc04450, 0) 12-02-08 11:29:02 I: zloop: polling for 397 msec 12-02-08 11:29:02 I: zloop: call SUB socket handler (0x7fbf5bc04450, 0) 12-02-08 11:29:02 I: asking for snapshot from: tcp://localhost:5556

Then the primary clone server starts spitting out a lot of output in the console with the following lines without any client connected:

CLIENT REQUEST 12-02-08 11:29:26 I: zloop: polling for 670 msec 12-02-08 11:29:26 I: zloop: call ROUTER socket handler (0x7fb6924018a0, 0) CLIENT REQUEST 12-02-08 11:29:26 I: zloop: polling for 670 msec 12-02-08 11:29:26 I: zloop: call ROUTER socket handler (0x7fb6924018a0, 0) CLIENT REQUEST 12-02-08 11:29:26 I: zloop: polling for 670 msec 12-02-08 11:29:26 I: zloop: call ROUTER socket handler (0x7fb6924018a0, 0) CLIENT REQUEST 12-02-08 11:29:26 I: zloop: polling for 670 msec 12-02-08 11:29:26 I: zloop: call ROUTER socket handler (0x7fb6924018a0, 0) CLIENT REQUEST 12-02-08 11:29:26 I: zloop: polling for 670 msec 12-02-08 11:29:26 I: zloop: call ROUTER socket handler (0x7fb6924018a0, 0) CLIENT REQUEST 12-02-08 11:29:26 I: zloop: polling for 670 msec 12-02-08 11:29:26 I: zloop: call ROUTER socket handler (0x7fb6924018a0, 0) CLIENT REQUEST 12-02-08 11:29:26 I: zloop: polling for 670 msec 12-02-08 11:29:26 I: zloop: call ROUTER socket handler (0x7fb6924018a0, 0) CLIENT REQUEST 12-02-08 11:29:26 I: zloop: polling for 670 msec 12-02-08 11:29:26 I: zloop: ca

I then try to connect client and it send messages OK but every so often they seem to detect that the primary clone server is down with the following output:

MacBookPro:C matt$ clonecli6 12-02-08 11:31:41 I: adding server tcp://localhost:5556... 12-02-08 11:31:41 I: waiting for server at tcp://localhost:5556... 12-02-08 11:31:41 I: adding server tcp://localhost:5566... /client/8401 /client/7984 /client/3352 /client/5539 /client/3647 12-02-08 11:31:46 I: server at tcp://localhost:5556 didn't give hugz 12-02-08 11:31:46 I: waiting for server at tcp://localhost:5566... /client/9161 /client/1416 /client/2428 /client/1566 /client/1088 12-02-08 11:31:51 I: server at tcp://localhost:5566 didn't give hugz 12-02-08 11:31:51 I: waiting for server at tcp://localhost:5556... /client/5129 /client/2960

My environment is Mac OSX 10.7.2 with ZeroMQ version 2.1.11

$ grep connect examples//rrserver |grep -v println
examples/C++/rrserver.cpp: responder.connect("tcp://localhost:5560");
examples/C/rrserver.c: zmq_connect (responder, "tcp://localhost:5560");
examples/CL/rrserver.lisp: (zmq:connect responder "tcp://localhost:5560")
examples/Erlang/rrserver.es: ok = erlzmq:connect(Responder, "tcp://*:5560"),
examples/Haskell/rrserver.hs: connect responder "tcp://localhost:5560"
examples/Haxe/rrserver.hx: responder.connect("tcp://localhost:5560");
examples/Java/rrserver.java: responder.connect("tcp://localhost:5560");
examples/Lua/rrserver.lua:responder:connect("tcp://localhost:5560")
examples/PHP/rrserver.php:$responder->connect("tcp://localhost:5560");
examples/Perl/rrserver.pl:$responder->connect('tcp://localhost:5560');
examples/Python/rrserver.py:socket.connect("tcp://localhost:5560")
examples/Ruby/rrserver.rb:socket.connect('tcp://localhost:5560')
examples/Scala/rrserver.scala: receiver.connect("tcp://localhost:5560")

I think those should all be using the bind call and not a connect call for the server example.

The example of asynchronous server written in python doesn't work. I've made some changes to make it work.
The diff is here

Section:
"Multithreading with zeromq"

Code example:
mtserver: Multithreaded service in C

In this example the frontend socket is of type "ZMQ_ROUTER" and the backend of type "ZMQ_DEALER". The documentation of the zmq_queue recommends to use "ZMQ_XREP" for the frontend and "ZMQ_XREQ" for the backend.

The zmq_queue claims to return response messages to the same client that sent the request. Im my project the use of the ROUTER/DEALER sockets lead to strange routing effects using multithreaded clients.

Btw: if i recall correctly ZMQ_XREP / ZMQ_XREQ are deprecated and replaced by ZMQ_REP and ZMQ_REQ respectively.

// in The Socket API section's first sample code

zmq_msg_t mouse;
mouse = zmq_msg_init (&mouse); // <-- this line must exist bug
zmq_recv (mousetrap, &mouse, 0);

Am having some problems getting the bstarsrv2 example to work. I start up two processes, a master and a slave and they connect and show the right messages. Then when I start up the client process bstarcli, the master prints out many lines containing CLIENT REQUEST and the client

The console output is as follows:

bstarsrv2 -p
I: Primary master, waiting for backup (slave) 12-02-07 13:54:00 I: connected to backup (slave), ready as master CLIENT REQUEST CLIENT REQUEST CLIENT REQUEST CLIENT REQUEST CLIENT REQUEST ...

bstarsrv2 -b
I: Backup slave, waiting for primary (master) 12-02-07 13:54:00 I: connected to primary (master), ready as slave

bstarcli
I: connecting to server at tcp://localhost:5001... W: no response from server, failing over I: connecting to server at tcp://localhost:5002... W: no response from server, failing over I: connecting to server at tcp://localhost:5001... W: no response from server, failing over I: connecting to server at tcp://localhost:5002... W: no response from server, failing over

In Chapter 2, Figure 28 for example, you have:

[[code type="textdiagram"]]
            +-------------+
  Frame 1   | Key         |     Subscription key
            +-------------+
  Frame 2   | Identity    |     Address of publisher
            +-------------+
  Frame 3   | Data        |     Actual message body
            +-------------+


    Figure # - Pub-sub envelope with sender address
[[/code]]

And in the image generated from it: https://github.com/imatix/zguide/raw/master/images/fig28.png, the hyphen over-writes the 'pub' in 'pub-sub'.

Matthew Horsfall (alh)
http://dyn.com

On my machine libzmq.so is installed under /usr/local/lib so I set the following environment variables in examples/C/build

INCDIR="/usr/local/include"
LIBDIR="/usr/local/lib"

This causes the c build script to try and link to everything under /usr/local/lib/*.a (450 libraries). I remove the following chunk of code to fix the issue, its not clear why its even there.

if [ "$LINKUP" = "yes" -o /$1/ = // ]; then
LIBLIST=""
for LIBRARY in lib_.a $LOCALLIBDIR/lib_.a $LIBDIR/lib_.a; do
if [ ! -f $LIBRARY ]; then
continue
fi
# Pull out the xxx from libxxx.a (or similar)
LIBNAME=basename $LIBRARY | sed -e 's/^...([^.]_)..*$/\1/'
LIBLIST="$LIBLIST -l$LIBNAME"
done
LIBLIST="$LIBLIST $STDLIBS $CCLIBS"
fi

The Erlang examples use not (yet?) existing API:

https://github.com/imatix/zguide/blob/master/examples/Erlang/asyncsrv.es#L65
https://github.com/imatix/zguide/blob/master/examples/Erlang/identity.es#L16
https://github.com/imatix/zguide/blob/master/examples/Erlang/msgqueue.es#L19
https://github.com/imatix/zguide/blob/master/examples/Erlang/mtserver.es#L36
https://github.com/imatix/zguide/blob/master/examples/Erlang/rtpapa.es#L31

Is that work in progress or left overs from the original first version erlzmq?

Hi,

The file is : /zguide/blob/master/examples/Java/syncsub.java
from https://github.com/pieterh

It's a kind of copy/paste bug at line 22. If i'm not mistaken...

replace
subscriber.connect("tcp://localhost:5562");

with this one
syncclient.connect("tcp://localhost:5562");

Bye,

Hi, I think the taskvent example has one issue with the "start batch" behavior.
The producer should send the start batch to the sink, not the workers, to signal that the processing has begun. As it is now, the sink receives the first answer of a worker and interprets it as the start batch (and one of the workers receives the start batch).

Maybe the code should look like this:

void *sink = zmq_socket (context, ZMQ_PUSH);
zmq_connect (sink, "tcp://localhost:5558");
//  The first message is "0" and signals start of batch
s_send (sink, "0");
...
zmq_close(sink);

Cheers,
Michael

on Darwin, gcc is used to link. gcc does not know to implicitly link with -lstdc++ [the standard C++ libraries], so the build fails:

durapub.cpp
i686-apple-darwin10-g++-4.2.1: -lzmq: linker input file unused because linking not done
Undefined symbols:
"vtable for std::basic_streambuf<char, std::char_traits >", referenced from:
_main in durapub.opp
_main in durapub.opp
_main in durapub.opp
"operator new(unsigned long)", referenced from:
s_recv(zmq::socket_t&) in durapub.opp
"std::basic_string<char, std::char_traits, std::allocator >::basic_string(char const*, std::allocator const&)", referenced from:
_main in durapub.opp
"vtable for std::basic_stringbuf<char, std::char_traits, std::allocator >", referenced from:
...

The list of undefined symbols:

$ ./c -p -l -lzmq -v durapub.cpp | grep referenced | awk '!x[$0]++'
"vtable for std::basic_streambuf<char, std::char_traits >", referenced from:
"operator new(unsigned long)", referenced from:
"std::basic_string<char, std::char_traits, std::allocator >::basic_string(char const_, std::allocator const&)", referenced from:
"vtable for std::basic_stringbuf<char, std::char_traits, std::allocator >", referenced from:
"std::ios_base::Init::Init()", referenced from:
"operator delete(void_)", referenced from:
"__cxa_call_unexpected", referenced from:
"std::ios_base::~ios_base()", referenced from:
"vtable for __cxxabiv1::__si_class_type_info", referenced from:
"typeinfo for std::exception", referenced from:
"std::basic_ios<char, std::char_traits >::init(std::basic_streambuf<char, std::char_traits >)", referenced from:
"___gxx_personality_v0", referenced from:
"VTT for std::basic_ostringstream<char, std::char_traits, std::allocator >", referenced from:
"std::locale::~locale()", referenced from:
"std::basic_string<char, std::char_traits, std::allocator >::_Rep::_S_empty_rep_storage", referenced from:
"std::_throw_logic_error(char const)", referenced from:
"std::basic_ostream<char, std::char_traits >& std::_ostream_insert<char, std::char_traits >(std::basic_ostream<char, std::char_traits >&, char const, long)", referenced from:
"___cxa_free_exception", referenced from:
"vtable for std::exception", referenced from:
"std::ios_base::ios_base()", referenced from:
"std::basic_string<char, std::char_traits, std::allocator >::_Rep::_S_create(unsigned long, unsigned long, std::allocator const&)", referenced from:
"std::basic_string<char, std::char_traits, std::allocator >::_Rep::M_destroy(std::allocator const&)", referenced from:
"std::ios_base::Init::~Init()", referenced from:
"std::locale::locale()", referenced from:
"vtable for std::basic_ostringstream<char, std::char_traits, std::allocator >", referenced from:
"std::exception::~exception()", referenced from:
"std::basic_ostringstream<char, std::char_traits, std::allocator >::~basic_ostringstream()", referenced from:
"std::basic_string<char, std::char_traits, std::allocator >::basic_string(char const, unsigned long, std::allocator const&)", referenced from:
"___cxa_allocate_exception", referenced from:
"___cxa_throw", referenced from:
"std::basic_string<char, std::char_traits, std::allocator >::assign(std::basic_string<char, std::char_traits, std::allocator > const&)", referenced from:
"vtable for std::basic_ios<char, std::char_traits >", referenced from:
"std::basic_ostream<char, std::char_traits >::operator<<(int)", referenced from:

Suggested Fix:

$ git diff
diff --git a/examples/C++/c b/examples/C++/c
index e65b189..526291a 100755
--- a/examples/C++/c
+++ b/examples/C++/c
@@ -178,6 +178,7 @@ if [ "$CCNAME" = "gcc" ]; then
elif [ "$UTYPE" = "Darwin" ]; then
# Use -start-group / -end-group for linking
LINKTYPE="after"

•    STDLIBS="$STDLIBS -lstdc++"
  

  Solaris-specific subsection

in chapter 1, it introduce zhelpers.h.
in chapter 2,3, it use other functions z_dump, z_sendmore which is not showed in chapter 1's zhelpers.h.

So, I suggest, the full zhelpers.h should suggest guide readers to download from
http://github.com/imatix/zguide/raw/master/examples/C/zhelpers.h

In last chapter 2, syncpub.c sleep(1) is not enough for me on my eee pc. So, I suggest, change it to function which could detect when will all data sent.

Source needs updated. Incorrect binding procedure used.

Python examples have no indentation in the web based code viewer. For example in the python hello world example the code under the for loop is not indented properly. This is a problem with the way the code is being displayed in the wiki. This is not a problem with the python code. Look at this link and notice the lack of indentations. http://zguide.zeromq.org/py:hwclient

I'm not familiar with the zguide code, this may be a separate issue with the wiki.

Hi!

I think it would be very useful to have a link to the examples in the preface of The Guide.
And a few words explaining where and how to get the example code would be awesome. :)

Cheers
Guido

PS: Just had that problem on irc.

Python "version" example is missing, but I guess we can resolve it by simply copying examples/Python/zversion.py to examples/Python/version.py.

Hi.
I'm reading zguide / examples / C / zhelpers.h and in function s_console (row 179) I see a malloc(20); but the strftime should use all of them for the resulting string (10 for y-m-d, 8 for h:m:s, 2 for spaces), so the malloc'd buffer has no space for the trailing '\0'.

in examples/C/mdcliapi.c of the majordomo pattern

the service name comparison seems flawed

 char *service = zmsg_pop (msg);
 assert (strcmp (service, service) == 0);
 free (service);

the service variable name is defined as an input parameter already and this code practically hides the variable. a compiler should even warn or fail. if it did compile though the expression should always be true...and thus irrelevant.

Did you mean to say:

 char *serviceAddressed = zmsg_pop (msg);
 assert (strcmp (serviceAddressed, service) == 0);
 free (serviceAddressed);

or something like it or am i missing something ?

So that "text search" can be done over guide (or whole table of contents) / faster navigation, etc.

Perl example loses space after 'sub':

subwithin {
    my ($upper) = @_;

    return int(rand($upper)) + 1;
}

Just downloaded zeromq-2.1.4 and I am a complete newbie. I am building ZeroMQ on MS VS C++ 2010 and I ran into a couple of issues:

(1) I wanted to test both 32 bit and 64 bit clients. There was no 64 bit platform in the zeromq-2.1.4\builds\msvc\msvc.sln
(2) When it upgraded the msvc solution (I guess it was in VS C++ 2008) it gave me several quite harmless warnings about the target path. For example:

warning MSB8012:
TargetPath(E:\ZeroMq\zeromq-2.1.4\builds\msvc\Debug\libzmq.dll) does not match the Linker's OutputFile property value (E:\ZeroMq\zeromq-2.1.4\lib\libzmq.dll). This may cause your project to build incorrectly. To correct this, please make sure that $(OutDir), $(TargetName) and $(TargetExt) property values match the value specified in %(Link.OutputFile).

(3) The output Files (linker->Output File) for both Debug and Release Win32 where set to ../../../lib/ libzmq.dll. I think I’m just lazy but I personally like to be able to just build all of them and have them in one place. Then reference the correct platform/configuration as the clients require. Perhaps this is the convention that was selected; however, I would like to find out if it’s just me or if ../../../lib/$(Platform)/$(Configuration)/libzmq.dll would be acceptable?

(4) When I did do the build it provided some additional warnings that seem to be harmless about “this” used in base member initialize list like the following:

warning C4355: 'this' : used in base member initializer list e:\zeromq\zeromq-2.1.4\src\xsub.cpp

However, I’m not entirely sure if these are really issues, it could just be my inexperience. I thought it might be helpful to address them ahead of time as I could always undo them. Here were my resolutions of the issues I describe

(1) Added a 64Bit platform and went through each configure and made sure all the correct C++ properties were set for libzmq, local_lat, local_thr, remote_lat, and remote_thr projects.

(2) I removed all the harmless warnings about TargetPath in libzmq, local_lat, local_thr, remote_lat, and remote_thr for MS VC++ 2010.

What I did was (for all configurations and all platforms):
a. Changed Configuration Properties -> General->Output Directory to: $(SolutionDir)$(Platform)$(Configuration)
b. Changed Configuration Properties -> General->Intermediate Directory to: $(Platform)$(Configuration)
c. Changed Configuration Properties->Linker->Output file to: $(OutDir)$(TargetFileName)

(3) After making changes in (2) above I had to get the files to the lib and bin directories as they were:

a. For libzmq (for all configurations and all platforms) I added the following to Configuration Properties->Build Events->Post-Build Event:

xcopy $(TargetPath) ......\lib$(Platform)$(Configuration)_._ /Y /D
xcopy $(TargetDir)$(TargetName).pdb ......\lib$(Platform)$(Configuration)_._ /Y /D

Output files or libzmq will be in:
i. Lib\Win32\Debug
ii. Lib\Win32\Release
iii. Lib\x64\Debug
iv. Lib\x64\Release

b. For local_lat, local_thr, remote_lat (for all configurations and all platforms) I added the following to Configuration Properties->Build Events->Post-Build Event:

xcopy $(TargetPath) ......\bin$(Platform)$(Configuration)_._ /Y /D
xcopy $(TargetDir)$(TargetName).pdb ......\bin$(Platform)$(Configuration)_._ /Y /D

Output files or local_lat, local_thr, remote_lat will be in:
i. Bin\Win32\Debug
ii. Bin\Win32\Release
iii. Bin\x64\Debug
iv. Bin\x64\Release

In not sure if any of these suggestions are helpful or useful to anyone. It is probably just a personal preference. If it would be helpful I can submit the new msvc10.slv and all the new vcxproj files for the changes I describe above (libzmq.vcxproj, local_lat.vcxproj, local_thr.vcxproj, remote_lat.vcxproj, and remote_thr.vcxproj). If it is helpful to someone could anyone point me in the direction where I could provide these?

For PDFer's, it would be bonus to have an official PDF version of all 0MQ documentation.

dead link

I tried to run the peering3 example from the zguide and am getting the following error message. I tried running with the C-binding and also with the Python binding and get the same error.

MacBookPro:C matt$ peering3 me you I: preparing broker at me... I: connecting to cloud frontend at 'you' I: connecting to state backend at 'you' Too many open files (signaler.cpp:330)

I am running it on my laptop with Mac OSX (Lion) 10.7.2 with ZeroMQ version 2.1.11 and Czmq version 1.1.0.

First I build the hwserver.c and run it. Then I try and run python hwclient.py, but there is no response. Even if I swap the c server with the haskell server, and run the python hwclient, there is no response. I can however run the python hwserver and hwclient fine together. Any ideas what the problem might be? Please let me know if this actually does work on another machine. I am running on osx 10.7.

Hi!

Just a few points I noticed while reading the new Ch4 parts.

• Asynchronous Majordomo Pattern - "Using raw TCP sockets you can switch off this delay, but ØMQ doesn't expose this option" should mention that ØMQ disables Nagle.
• above Service Discovery - "... without a more work ..." - the "a" seems to be misplaced.
• Fire-and-Forget Reliability - "... spinning rust ..." - the definition/explanation should be worth a side or footnote.
• Fire-and-Forget Reliability - "... sitting in the center of your architecture:" - seems that an "are" is missing.

Cheers
Guido

chapter: A Publish-Subscribe Proxy Server

Wouldn't it make sense for the clients to use the same port as the server so the examples were runnable against themselves?

Compare the output below:

$ grep connect examples//rrclient|grep -v println
examples/C++/rrclient.cpp: requester.connect("tcp://localhost:5559");
examples/C/rrclient.c: zmq_connect (requester, "tcp://localhost:5559");
examples/CL/rrclient.lisp: (zmq:connect requester "tcp://localhost:5559")
examples/Erlang/rrclient.es: ok = erlzmq:connect(Requester, "tcp://*:5559"),
examples/Haskell/rrclient.hs: connect requester "tcp://localhost:5559"
examples/Haxe/rrclient.hx: requester.connect ("tcp://localhost:5559");
examples/Java/rrclient.java: requester.connect("tcp://localhost:5559");
examples/Lua/rrclient.lua:requester:connect("tcp://localhost:5559")
examples/PHP/rrclient.php:$requester->connect("tcp://localhost:5559");
examples/Perl/rrclient.pl:$requester->connect('tcp://localhost:5559');
examples/Python/rrclient.py:socket.connect("tcp://localhost:5559")
examples/Racket/rrclient.rkt:(socket-connect! sock "tcp://localhost:5559")
examples/Ruby/rrclient.rb:socket.connect('tcp://localhost:5559')
examples/Scala/rrclient.scala: requester.connect ("tcp://localhost:5559")

$ grep connect examples//rrserver |grep -v println
examples/C++/rrserver.cpp: responder.connect("tcp://localhost:5560");
examples/C/rrserver.c: zmq_connect (responder, "tcp://localhost:5560");
examples/CL/rrserver.lisp: (zmq:connect responder "tcp://localhost:5560")
examples/Erlang/rrserver.es: ok = erlzmq:connect(Responder, "tcp://*:5560"),
examples/Haskell/rrserver.hs: connect responder "tcp://localhost:5560"
examples/Haxe/rrserver.hx: responder.connect("tcp://localhost:5560");
examples/Java/rrserver.java: responder.connect("tcp://localhost:5560");
examples/Lua/rrserver.lua:responder:connect("tcp://localhost:5560")
examples/PHP/rrserver.php:$responder->connect("tcp://localhost:5560");
examples/Perl/rrserver.pl:$responder->connect('tcp://localhost:5560');
examples/Python/rrserver.py:socket.connect("tcp://localhost:5560")
examples/Ruby/rrserver.rb:socket.connect('tcp://localhost:5560')
examples/Scala/rrserver.scala: receiver.connect("tcp://localhost:5560")

Hi,

Please refer to comments in the mailing list for context of this issue:

http://comments.gmane.org/gmane.network.zeromq.devel/9493

To summarize: please add a paragraph warning the reader about doing PUB.connect() and SUB.bind() in the PUB/SUB model. As discovered in the issue above, the orthodox approach is PUB.bind() and SUB.connect(), where PUB discards messages when no SUB is around.

Thanks!

Jia Li

If you want to send the same message more than once, create a second message, initialize it using zmq_init(3) and then use zmq_msg_copy(3) to create a copy of the first message.

should be zmq_msg_init here

When building C samples on snow leopard using

$ gcc -v
Using built-in specs.
Target: i686-apple-darwin10
Configured with: /var/tmp/gcc/gcc-5659~1/src/configure --disable-checking --enable-werror --prefix=/usr --mandir=/share/man --enable-languages=c,objc,c++,obj-c++ --program-transform-name=/^[cg][^.-]*$/s/$/-4.2/ --with-slibdir=/usr/lib --build=i686-apple-darwin10 --program-prefix=i686-apple-darwin10- --host=x86_64-apple-darwin10 --target=i686-apple-darwin10 --with-gxx-include-dir=/include/c++/4.2.1
Thread model: posix
gcc version 4.2.1 (Apple Inc. build 5659)

The build complains about uint:

lruqueue2.c
In file included from lruqueue2.c:16:
zmsg.h: In function ‘zmsg_dup’:
zmsg.h:212: error: ‘uint’ undeclared (first use in this function)
zmsg.h:212: error: (Each undeclared identifier is reported only once
zmsg.h:212: error: for each function it appears in.)
zmsg.h:212: error: expected ‘;’ before ‘part_nbr’
zmsg.h:213: error: ‘part_nbr’ undeclared (first use in this function)

suggested fix:

diff --git a/examples/C/zhelpers.h b/examples/C/zhelpers.h
index 232457c..ecb1d1e 100644
--- a/examples/C/zhelpers.h
+++ b/examples/C/zhelpers.h
@@ -49,6 +49,9 @@
typedef unsigned long ulong;
typedef unsigned int uint;
typedef int64 int64_t;
+#elif (defined (__APPLE))

• typedef unsigned long ulong;
• typedef unsigned int uint;

endif

// Provide random number from 0..(num-1)

Hi,

I found some problem in the parallel pipeline example:

taskvent.cs ( https://github.com/imatix/zguide/blob/master/examples/C%23/taskvent.cs )
line 22
sender.Connect("tcp://localhost:5557");
instead of
sender.Bind("tcp://*:5557");

taskwork.cs ( https://github.com/imatix/zguide/blob/master/examples/C%23/taskwork.cs )
line 9
sender.Connect("tcp://localhost:5557");
instead of
receiver.Connect("tcp://localhost:5557");

line 28
sender.Connect("tcp://localhost:5557");
instead of
sender.Connect("tcp://localhost:5558");

Also I would remove the multiplication from
t = Convert.ToInt32(_string) * 1000;
because it produces incorrect results and too long running.

tasksink.cs ( https://github.com/imatix/zguide/blob/master/examples/C%23/tasksink.cs )
line 22
receiver.Connect("tcp://localhost:5558");
instead of
receiver.Bind("tcp://*:5558");

Just found these little bugs last week,
Thank you again, these examples helps me a lot,

pinusnegra

Add --depth=1 to the git clone command at the beginning:
git clone git://github.com/imatix/zguide.git

This just checks out the most recent version and currently saves ~7MB per checkout.

There are a number of little API issues with the Ruby code in the examples. Course, this could because I am a total newbie at 0MQ as well...

I am slowing fixing them, should I fork and submit a pull request for the ruby code, or just attach patch files?

ERic

Figure 23 in "Node Coordination" has the REQ in the Publisher and REP in the Subscriber, when the code (and intent) has it flipped (Publisher is REP, Subscriber is REQ)

Hi, the taskvent Java example has a flaw, it sleeps too long:

http://zguide.zeromq.org/java:taskwork

The received time to sleep is multiplied by 1 000 000 and passed to the [Thread.sleep](http://download.oracle.com/javase/6/docs/api/java/lang/Thread.html#sleep(long\)) method (taking millis to sleep, not nanos as the code suggests).

A simple fix would be to remove the multiplication and rename the variable to msec:

long msec = Long.parseLong(string);
//  Simple progress indicator for the viewer
System.out.flush();
System.out.print(string + '.');

 //  Do the work
Thread.sleep(msec);

Cheers,
Michael

Split the lruqueue C code into two programs, one multi-client, one server, then the client hangs in zmq_term unless you modify the code to close each 0MQ socket before closing the thread, i.e.

--- lruqueue.c  2010-12-08 12:39:08.000000000 +0800
+++ client.c    2010-12-08 12:59:14.000000000 +0800
@@ -17,6 +17,8 @@
     char *reply = s_recv (client);
     printf ("Client: %s\n", reply);
     free (reply);
+
+    zmq_close (client);
     return (NULL);
 }

This is the line 49 of mtserver.java
---ZMQ.device(ZMQ.QUEUE, clients, workers);
but it can be compiled because the QUEUE constant can't be found in the ZMQ.java(http://github.com/zeromq/jzmq), any suggestion about it? Thanks.

Incomplete Copy-paste in Java durasub.java example. Please check it.

must the chunk be copied somewhere, and the rest appended on each iteration ? or is the msg at the last iteration complete for usage ?

When using "./build all" in the C++ examples directory on Ubuntu 11.10 the build repeatedly fails at the linking stage.

This can be solved by moving the linker flags on line 469 of the script c:
Current: COMMAND="$CCNAME $CCOPTS $FILENAME.$OBJEXT -o $FILENAME"
Edited: COMMAND="$CCNAME $FILENAME.$OBJEXT $CCOPTS -o $FILENAME"

A Lisper following along with the examples from the web page will be stymied because they require ZHELPERS. Best thing to do is include a link to zhelpers.lisp in the source tree, as for C.

Two more notes:

• Fire-and-Forget Reliability - "... (think of email as an analogy), we can't use a stateless in between clients and workers." - stateless what?
• Fire-and-Forget Reliability below pic 61 - "You can work though this, and..." - through

Cheers
Guido

See: http://zguide.zeromq.org/py:mtrelay

The last 2 lines of the example are correct in the source, reading:

if __name__ == "__main__":
    main()

but render as:

if name == "main":
    main()

Minor but may be confusing to folks.
where name and "main" are underlined.

Hi,
Just a small problem:

In example
https://github.com/imatix/zguide/blob/master/examples/C%23/wuclient.cs
There is a missing line:
subscriber.Connect("tcp://localhost:5556");

Thank you for your C# examples,

pinusnegra