Learning and Using ØMQ

Is there a way to incorporate the examples from your blog into the book/the guide on zeromq.org? I'm going to implement them now (even if I don't like the format of a zcert file).

• Restore non-C# changes lost when #600 was integrated
• Re-integrate just the desired C# changes from #600

@chubbson can you review the C# examples make sure they're in the desired state?

ref: http://lists.zeromq.org/pipermail/zeromq-dev/2015-December/029903.html

Hello,

I was wondering if any epub version of the zguide was available? Is someone is interested working about this with me if it's the case?

Best regards

Rémy

java examples class names starts with lowercase however java standard conventions states class name and file name should starts with capitalcase. I think it's because build process. but I can't understand the mechanism. Is there any possible soloution to change java example class names to correct one without breaking the build process?

Also fixed a bstarcli.py bug where the poller was not updated to poll the new client after it was created, so would perpetually failover.

And adds the titanic/ticlient files I mentioned but forgot in the previous PR.

I think it would be a good idea to include in the travis-ci all the required steps to build the guide. I can't find the docs to build the guide easily...

Also you need to activate travis-ci hook for this repo. It's free :-)

How do you just generate this awesome link to watch the ZGuide in Python?

zguide.zeromq.org/py:all

Would you also like to make a link for the ZGuide in C#?

zguide.zeromq.org/cs:all

http://zguide.zeromq.org/page:all

The link leads to an empty page with just the header. This seems to break internal links as well.

Chapter links like http://zguide.zeromq.org/py:chapter1 do work.

I'm working on unit tests for code that uses 0mq and I'm finding the zguide section "Getting the Context Right" pretty restrictive.

1. A process can only have one context.
2. The context must be created once and destroyed once in a process.
3. The context must be created after any fork.

Each of my tests creates and destroys a context. Some of the tests fork to create a process to talk to. All the tests work, but clearly, I'm skiing off piste.

Restrictions 1 and 2 can be got around using reference counting, but restriction 3 is the last straw. Is there any wiggle room here? If, for example, it were possible to create and destroy a context more than once, I could meet the other restrictions without exposing them to the application.

Hi,

I've just started looking into ZeroMQ and noticed that the Go examples could use some love.

The bindings from http://github.com/alecthomas/gozmq are no longer maintained and the author suggests to use the ones from Peter Kleiweg (http://github.com/pebbe/zmq[234]). The API has some slight differences. (e.g. context.Term() instead of context.Close())

Also, the examples are missing the error handling and use debug functions (println).

I'm happy to do the work and send in a pull request if that's OK?

Frank

When do you plan to make a new version of the ZGuide?

Should I rename all the sample files to lower-cased names, for the build-script?

https://github.com/metadings/zguide/tree/master/examples/C%23

The example wuclient.py at https://zguide.zeromq.org/docs/chapter1/#Getting-the-Message-Out has incorrect indentation at L24 (7 spaces instead of 8 spaces). This PR corrects the indentation.

First, ZeroMQ is awesome, I've been using it for years. However, I'm working on an idea that may need to transition communication from between threads into between processes, and then possibly outward even more into communication over IP. While I can obviously make this work without using ZMQ_PAIR for ipc:// or tcp://, I'm still confused regarding the state of this "experimental" status. To be honest we can only assume that this experimental status only applies to network based sockets because the documentation is not specific on that note. I believe this should be covered in a little more detail, at least to a point where a user isn't left to assume. The specific foot note I'm referring too:

ZMQ_PAIR sockets are designed for inter-thread communication across the zmq_inproc(7) transport and do not implement functionality such as auto-reconnection. ZMQ_PAIR sockets are considered experimental and may have other missing or broken aspects.

http://api.zeromq.org/master:zmq-socket

[edit] I'm posting this here because I believe it's more of a documentation bug than an implementation bug. The specific behavior when using ZMQ_PAIR is understandable, and it's difference between other socket types is understandable as well given the non-trivial difference of communication between endpoints which are in fact related threads. I just feel it's a bit of a hole in the documentation when considering how well ZMQ is otherwise covered inside and out.

I used C++example of mdwrkapi in a new solution。In the windows program, the example codes compile and run normally。In the Linux ，I used ubuntu，the same code will throw a running error 。I found that the zmq_msg_close() returned 0 in Windows but returned -1 in Linux ，and Linux throwed the e.what() of Bad address。I have no idea about this problem。

In the program, the message sending length is more than 4K bytes and the frequency is more than 1 millisecond. After a long time of execution, it is easy to produce abort error.

Viewing the coredump information, it is easy to make mistakes when applying for or releasing the buffer size in the ZMQ API interface zmq_msg_init_size or zmq_msg_close. If the sending frequency remains unchanged, there will be no error when reducing the message length (such as 1K bytes).

Has anyone ever had a similar problem?

This is a reproducible message silently dropped issue with a very small changes to the lbbroker.cpp.

https://github.com/booksbyus/zguide/blob/master/examples/C%2B%2B/lbbroker.cpp

In the lbbroker.cpp file, a worker will be pop out from work_queue when handling a request from client thread. If we modify the line 163 from "std::string worker_addr = worker_queue.front();" to "static std::string worker_addr = worker_queue.front();", as the following picture shows. All request will be forwarded to one worker, then we can see some messages will be dropped by the REQ socket the worker. Is it normal? REQ socket cannot receive other message when the worker logic is running ?