zeromq / azmq Goto Github PK

I tried compiling on ubuntu 14.04 with linuxbrew and ran into a linker error. Here are detailed logs of the commands, of particular interest are the following lines:

cd /tmp/azmq20151012-78042-1a178n2/test/socket && /home/hbr/.linuxbrew/Cellar/cmake/3.3.2/bin/cmake -E cmake_link_script CMakeFiles/test_socket.dir/link.txt --verbose=1
/home/hbr/.linuxbrew/bin/g++-5   -Os -w -pipe -march=core2  --std=c++11   -L/home/hbr/.linuxbrew/lib -Wl,--dynamic-linker=/home/hbr/.linuxbrew/opt/glibc/lib/ld-linux-x86-64.so.2 -Wl,-rpath,/home/hbr/.linuxbrew/lib CMakeFiles/test_socket.dir/main.cpp.o  -o test_socket -rdynamic -lboost_system-mt -lboost_log-mt -lboost_date_time-mt -lboost_thread-mt -lboost_chrono-mt -lboost_regex-mt -lboost_random-mt -lzmq 
/home/hbr/.linuxbrew/bin/ld: CMakeFiles/test_socket.dir/main.cpp.o: undefined reference to symbol 'pthread_create@@GLIBC_2.2.5'
/home/hbr/.linuxbrew/lib/libpthread.so.0: error adding symbols: DSO missing from command line
collect2: error: ld returned 1 exit status
test/socket/CMakeFiles/test_socket.dir/build.make:105: recipe for target 'test/socket/test_socket' failed
make[2]: *** [test/socket/test_socket] Error 1
make[2]: Leaving directory '/tmp/azmq20151012-78042-1a178n2'
CMakeFiles/Makefile2:286: recipe for target 'test/socket/CMakeFiles/test_socket.dir/all' failed
make[1]: *** [test/socket/CMakeFiles/test_socket.dir/all] Error 2
make[1]: *** Waiting for unfinished jobs....

These stackoverflow questions shed some light on the issue:

• Strange linking error: DSO missing from command line
• DSO missing from command line

Apparently a library which should be linked (pthread, glibc or both) is not being linked at the moment.

pthread and pthread_create is definitely found:

-- Looking for include file pthread.h
-- Looking for include file pthread.h - found
-- Looking for pthread_create
-- Looking for pthread_create - not found
-- Looking for pthread_create in pthreads
-- Looking for pthread_create in pthreads - not found
-- Looking for pthread_create in pthread
-- Looking for pthread_create in pthread - found
-- Found Threads: TRUE  

-lpthread is also linked for other tests:

cd /tmp/azmq20151012-78042-1a178n2/doc/examples/actor && /home/hbr/.linuxbrew/Cellar/cmake/3.3.2/bin/cmake -E cmake_link_script CMakeFiles/actor.dir/link.txt --verbose=1
/home/hbr/.linuxbrew/bin/g++-5   -Os -w -pipe -march=core2  --std=c++11   -L/home/hbr/.linuxbrew/lib -Wl,--dynamic-linker=/home/hbr/.linuxbrew/opt/glibc/lib/ld-linux-x86-64.so.2 -Wl,-rpath,/home/hbr/.linuxbrew/lib CMakeFiles/actor.dir/main.cpp.o  -o actor -rdynamic -lpthread -lzmq -lboost_system-mt -lboost_log-mt -lboost_date_time-mt -lboost_thread-mt -lboost_chrono-mt -lboost_regex-mt -lboost_random-mt 
make[2]: Leaving directory '/tmp/azmq20151012-78042-1a178n2'

This leads me to believe it is a problem in the cmake script for test/socket

I propose to rename azmq::message's string() function into to_string(). This approach consistent with STL naming (check bitset and string_view classes for example).

The current 'thread' functionality is substantially similar to CZMQ's zactor and is sufficient to implement a variety of lightweight reactive patterns (e.g. zbeacon functionality) using Asio and it's stackless coroutine support.

I intended to provide a stackless async facility to create multiple 'actors' within a single thread, but I am unsatisfied with the complexity the current solution introduces. If I reintroduce this functionality at a later date, it will be called something other than an 'actor'.

Currently, azmq::message move ctor/assignment implements the equivalent of zmq_msg_move(). This is not error prone against future changes in ZMQ. I propose to simply call zmq_msg_move() instead.

Btw, current implementation of move assignment has leak: existing message is not closed before assigning.

This introduces slightly inconsistent (and potentially surprising) behavior between sync and async receive and the case for waiting for some arbitrary, known ahead of time, number of messages, as opposed to message parts, is pretty thin.

I'm trying to destroy a socket while it is running and it keeps hanging on me consistently within zmq. Is there anything I need to do for this to happen correctly?

Here is a stack trace:

Thread (16)#0   0x00007fff8b62e5c2 in poll ()
#1  0x0000000116fddcb9 in zmq::signaler_t::wait(int) ()
#2  0x0000000116fd06b5 in zmq::mailbox_t::recv(zmq::command_t*, int) ()
#3  0x0000000116fc77fd in zmq::ctx_t::terminate() ()
#4  0x0000000116ff072f in zmq_ctx_term ()
#5  0x00000001169bd5a7 in std::__1::__shared_ptr_pointer<void*, int (*)(void*), std::__1::allocator<void> >::__on_zero_shared() at /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/../include/c++/v1/memory:3669
#6  0x00007fff890538a6 in std::__1::__shared_weak_count::__release_shared() ()
#7  0x00000001169bcccf in std::__1::shared_ptr<void>::~shared_ptr() at /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/../include/c++/v1/memory:4448
#8  0x00000001169bb6a5 in std::__1::shared_ptr<void>::~shared_ptr() at /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/../include/c++/v1/memory:4446
#9  0x00000001169bb82c in std::__1::shared_ptr<void>::reset() [inlined] at /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/../include/c++/v1/memory:4577
#10 0x00000001169bb76d in azmq::detail::socket_service::shutdown_service() at /usr/local/include/azmq/detail/socket_service.hpp:181
#11 0x00000001169a07ba in boost::asio::detail::service_registry::~service_registry() at /usr/local/include/boost/asio/detail/impl/service_registry.ipp:37
#12 0x00000001169a0765 in boost::asio::detail::service_registry::~service_registry() at /usr/local/include/boost/asio/detail/impl/service_registry.ipp:30
#13 0x00000001169a0730 in boost::asio::io_service::~io_service() at /usr/local/include/boost/asio/impl/io_service.ipp:53
#14 0x00000001169a0505 in boost::asio::io_service::~io_service() at /usr/local/include/boost/asio/impl/io_service.ipp:52
#15 0x00000001169a0401 in grl::KukaVrepPlugin::~KukaVrepPlugin() at /Users/athundt/source/robonetracker/modules/grl/include/grl/vrep/KukaLBRiiwaVrepPlugin.hpp:183

These do not really work as well in practice as they seemed they would at the time.

It may be wise to select outstanding issues that are important, resolve them, then create a release of azmq. This makes it easier to incorporate azmq into package management systems.

For example, I've created a small Homebrew formula, but I believe one of the preferred criteria is to have a release. I've also created an issue in homebrew for incorporating the formula.

E.g. aziomq::router, aziomq::dealer etc.

ASIO objects like sockets and timers follow the approach that an object destructor cancels all the active async operations with boost::asio::error::operation_aborted error. AZMQ socket doesn't do this, so operation handlers are never called if socket destroyed. I propose to change AZMQ to follow ASIO approach.

Need to port examples from aziomq4-x repo

There should be a way to close a socket (i.e. cancel all async operations and cleanup all resources associated with it, especially ZMQ socket) without calling a destructor. This is extremely useful in multi-threaded applications which tend to spread shared pointers. In such scenario, user has no simple control over socket object lifetime but may need to close it at exact point.
This story is somehow related to #77.

Current FindAzioMQ.cmake has several problems:

• Has outdated name (should be FindAZMQ.cmake).
• Provides AzioMQ_LIBRARIES although AZMQ is header only now.
• Extracts version in platform dependent way with using of grep.
• Doesn't do a version checking.

Because this file is need to be almost rewritten from scratch, I propose not only fix the problems but switch from CMake finder module approach to package config one (see http://www.cmake.org/Wiki/CMake/Tutorials/How_to_create_a_ProjectConfig.cmake_file). New approach is simpler in implementation than existing one and also gives ability to provide a list of dependent libraries for transitive linking.

In socket.hpp the option ZMQ_CURVE_SERVERKEY is not defined, it should be defined as follows:

using curve_publickey = opt::binary < ZMQ_CURVE_PUBLICKEY >;
using curve_privatekey = opt::binary < ZMQ_CURVE_SECRETKEY >;
using curve_serverkey = opt::binary < ZMQ_CURVE_SERVERKEY >;

Otherwise the curve security can not be used with zeromq. With this define, curve security is working

I propose to either update message::rebuild() so it has the same overloads as ctor or remove it completely because user can do assignment if needs to rebuild the message.
Due to large amount of overloads, latter approach looks more simple.

UPD: I would also consider to rename rebuild() into more standard reset().

There are few places where flag ZMQ_RCVMORE is passed to function zmq_msg_recv where it should has no meaning (see http://api.zeromq.org/4-0:zmq-msg-send). It's a bit confusing and I propose to remove this.

I believe that I will need have the backend thread of an Actor run without calling the service_io::run() method so in following the recommendations from the Actor class documentation I've tried setting the detached option on the client socket like so:

server_t::server_t( asio::io_service & ios, const char* name )
  : pimple_(std::make_shared<impl>(name))
  , frontend_(azmq::actor::spawn(ios, run, pimple_) )
{
  this->frontend_.set_option(azmq::actor::detached(true)); 
}

However this causes an exception (errno 22 invalid argument) to be thrown.
It appears the exception occurs because option gets passed on to the zmq socket after it is handled by ext handler and zmq_setsocketopt() returns a -1. See set_option() in socket_service.hpp, and set_option() in socket_ops.hpp.

Am I missing something or is this a bug?

How difficult it will be to rewrite azmq without boost? http://think-async.com/Asio/AsioStandalone

Add function const void * message::data() const noexcept;.

I propose to switch to using of Catch unit-test framework. Comparing to current approach it gives us easy to use assertions, main function which can run tests by pattern and JUnit compatible reporting which can be then used in CI.
Catch is header only and consists of only one header which we just put under test dir. It's licensed under Boost Software License 1.0 which fits us well.

I have a problem with monitoring events on Windows. Async receive completion handler for event is called, the received size is reported correctly (=6) but receiving buffer is not filled with event data.

To indicate that async operation was cancelled, ASIO uses boost::asio::error::operation_aborted while AZMQ uses boost::system::errc::operation_canceled. Mentioned errors are the same on Linux (POSIX to be precise), but different on Windows. This is error-prone, so AZMQ should use boost::asio::error::operation_aborted too.

Examples:
tcp://127.0.0.1:* bind to first free port from C000 up
tcp://127.0.0.1:! bind to random port from C000 to FFFF
tcp://127.0.0.1:*[60000-] bind to first free port from 60000 up
tcp://127.0.0.1:![-60000] bind to random port from C000 to 60000
tcp://127.0.0.1:![55000-55999] bind to random port from 55000-55999

In my fully asynchronous application, I need to keep track of the number of connections on some ZeroMQ sockets, for which I am using the socket monitor feature. However, because the monitoring socket pair uses the inproc transport, azmq resorts to polling for new events for implementing async_read. As a side effect, this leads to my program hogging 100% of its CPU core all of the time. Is there any chance to implement this more efficiently without changing ZeroMQ itself? (I'd like to avoid relying on a custom fork.)

As a workaround, I currently only check for new socket events on a timer. But this is obviously not ideal, as it introduces extra latency to the handling of these events.

There are a few items from asio I was hoping to use that don't appear to be supported yet, unless I am using things incorrectly. Thanks for taking a look!

Coroutine

asio coroutine + spawn overview
asio spawn reference

I saw spawn exists in actor.hpp, but that appears to be for a different purpose, unless I misunderstood.

Here is an example I tried to create based of the asio echo_server.cpp

Futures

asio futures overview
asio futures example

The following minimal example generates a few extra receive calls. The expected behavior is that the sockets and io_service should be possible to shut down and destroy while an async_receive call is outstanding. However, the actual behavior of the code below is that the application hangs and cannot exit due to what I believe is an azmq bug:

#include <mutex>
#include <iostream>
#include <memory>
#include <thread>


#include <azmq/socket.hpp>

/// Send messages between a client and server asynchronously. 
///
/// @see overview of zmq socket types https://sachabarbs.wordpress.com/2014/08/21/zeromq-2-the-socket-types-2/
/// @see bounce is based on https://github.com/zeromq/azmq/blob/master/test/socket/main.cpp
void bounce(std::shared_ptr<azmq::socket> sendP, std::shared_ptr<azmq::socket> receiveP, bool shouldReceive = true) {
            std::shared_ptr<std::atomic<int> > recv_countP(std::make_shared<std::atomic<int>>(0));
            std::shared_ptr<std::atomic<int> > send_countP(std::make_shared<std::atomic<int>>(0));

            constexpr int messagesToSend = 1000;
    int receiveAttempts = 0;

    for (int x = 0; (x<messagesToSend) || ((*recv_countP) < messagesToSend); ++x) {

        /////////////////////////////////////////
        // Client sends to server asynchronously!
        {
             sendP->async_send(boost::asio::buffer(&x, 4), [x,sendP,send_countP] (boost::system::error_code const& ec, size_t bytes_transferred) {
                    if(ec) std::cout << "SendFlatBuffer error! todo: figure out how to handle this\n";
                    else {
                      std::cout << "sent: " << x << "\n";
                      (*send_countP)++;
                    }

                });
        }

        //////////////////////////////////////////////
        // Server receives from client asynchronously!
        while
        (
                  shouldReceive && (*recv_countP < *send_countP)
               && (*recv_countP < messagesToSend)
               && (receiveAttempts < (*send_countP)-(*recv_countP))
        )
        {
            std::shared_ptr<int> recvBufP(std::make_shared<int>(0));
            BOOST_VERIFY(*recvBufP == 0);
            receiveP->async_receive(boost::asio::buffer(recvBufP.get(),sizeof(*recvBufP)), [recvBufP,receiveP,recv_countP, messagesToSend](boost::system::error_code const ec, size_t bytes_transferred) {

                if(ec) std::cout << "start_async_receive_buffers error! todo: figure out how to handle this\n";
                else std::cout << "received: " << *recvBufP << " recv_count:" << *recv_countP << "\n";
                // make rbp the size of the actual amount of data read
                (*recv_countP)++;
            });
            receiveAttempts++;
        }
        receiveAttempts = 0;

        //std::this_thread::sleep_for( std::chrono::milliseconds(1) );
    }
    sendP->get_io_service().stop();
    receiveP->get_io_service().stop();
    sendP.reset();
    receiveP.reset();
}


int main(int argc, char* argv[])
{

    std::string localhost("127.0.0.1");
    std::string localport("9998");
    std::string remotehost("127.0.0.1");
    std::string remoteport("9998");

    std::cout << "argc: " << argc << "\n";

    if (argc != 5 && argc != 1 && argc != 3)
    {
      std::cerr << "Usage: " << argv[0] << " <localip> <localport> <remoteip> <remoteport>\n";
      return 1;
    }

    bool shouldReceive = true;

    if(argc == 3){
      remotehost = std::string(argv[1]);
      remoteport = std::string(argv[2]);
      shouldReceive = false;
    }

    if(argc == 5){
      localhost = std::string(argv[1]);
      localport = std::string(argv[2]);
      remotehost = std::string(argv[3]);
      remoteport = std::string(argv[4]);
      shouldReceive = true;
    }

    std::cout << "using: "  << argv[0] << " ";
    if(shouldReceive) std::cout <<  localhost << " " << localport << " ";
    std::cout <<  remotehost << " " << remoteport << "\n";
    {
    boost::asio::io_service io_service;
    std::shared_ptr<azmq::socket> sendsocket = std::make_shared<azmq::socket>(io_service, ZMQ_DEALER);
    std::shared_ptr<azmq::socket> recvsocket = std::make_shared<azmq::socket>(io_service, ZMQ_DEALER);
    recvsocket->bind("tcp://" + localhost + ":" + localport);
    sendsocket->connect("tcp://"+ remotehost + ":" + remoteport);



    std::thread thr(bounce,sendsocket,recvsocket,shouldReceive);
    std::thread ios_t;

    {
        boost::asio::io_service::work work(io_service);
        ios_t = std::thread([&] {
            io_service.run();
        });
        sendsocket.reset();
        recvsocket.reset();
        thr.join();
    }

    io_service.stop();
    ios_t.join();
    }

  return 0;
}

I'm running d1f609d on OS X with zmq zeromq: stable 4.1.2 (bottled), HEAD from homebrew.

As mentioned in the title, 'azio' is shorter and much easier to memorize. And the code could be having a batter looking while working with 'asio'.

I have created a small subscriber application which uses the curve security. However the subscriber keeps disconnecting after a couple of minutes. After a couple of minutes I always the ZMQ_EVENT_DISCONNECTED event. Perhaps this is related to the curve security ?

This is the example I have created:

#include <azmq/socket.hpp>
#include <boost/asio.hpp>
#include <array>

namespace asio = boost::asio;

asio::io_service ios;
boost::shared_ptr<azmq::sub_socket> subscriber;
boost::shared_ptr<azmq::socket> monitor;
uint16_t monitor_event;

boost::array<char, 4096> buffer;

void ZeroMQHandleMonitor(boost::system::error_code const& error, azmq::socket::more_result_type result)
{
    if((monitor_event & ZMQ_EVENT_CONNECTED) == ZMQ_EVENT_CONNECTED)
        std::cout << "ZeroMQ connection established" << std::endl;

    if(monitor_event & ZMQ_EVENT_CONNECT_DELAYED)
        std::cout << "ZeroMQ connect delayed" << std::endl;

    if(monitor_event & ZMQ_EVENT_CONNECT_RETRIED)
        std::cout << "ZeroMQ connect retried" << std::endl;

    if(monitor_event & ZMQ_EVENT_LISTENING)
        std::cout << "ZeroMQ server listening" << std::endl;

    if(monitor_event & ZMQ_EVENT_BIND_FAILED)
        std::cout << "ZeroMQ bind failed" << std::endl;

    if(monitor_event & ZMQ_EVENT_ACCEPTED)
        std::cout << "ZeroMQ connection accepted" << std::endl;

    if(monitor_event & ZMQ_EVENT_ACCEPT_FAILED)
        std::cout << "ZeroMQ accept failed" << std::endl;

    if(monitor_event & ZMQ_EVENT_CLOSED)
        std::cout << "ZeroMQ connection closed" << std::endl;

    if((monitor_event & ZMQ_EVENT_CLOSE_FAILED) == ZMQ_EVENT_CLOSE_FAILED)
        std::cout << "ZeroMQ close failed" << std::endl;

    if((monitor_event & ZMQ_EVENT_DISCONNECTED) == ZMQ_EVENT_DISCONNECTED)
        std::cout << "ZeroMQ connection lost" << std::endl;

    if(monitor_event & ZMQ_EVENT_MONITOR_STOPPED)
        std::cout << "ZeroMQ monitor stopped" << std::endl;

    monitor->flush();
    monitor->async_receive_more(boost::asio::buffer(&monitor_event, sizeof(monitor_event)), ZeroMQHandleMonitor);
}

void message_received(boost::system::error_code const& ec, azmq::socket::more_result_type result)
{
    std::cout << std::string(buffer.data(), result.first) << std::endl; 
    subscriber->async_receive_more(boost::asio::buffer(buffer), message_received); 
}

int main(int argc, char** argv) 
{
    subscriber = boost::make_shared<azmq::sub_socket>(ios);

    subscriber->set_option(azmq::socket::tcp_keepalive(1));
    subscriber->set_option(azmq::socket::subscribe(""));

    monitor = boost::make_shared<azmq::socket>(ios, true);
    *monitor = subscriber->monitor(ios, ZMQ_EVENT_ALL);
    monitor->async_receive_more(boost::asio::buffer(&monitor_event, sizeof(monitor_event)), ZeroMQHandleMonitor);

        char client_public_key [41];
        char client_secret_key [41];
        zmq_curve_keypair(client_public_key, client_secret_key);

        std::vector<uint8_t> server_key =  ... ;

        subscriber->set_option(azmq::socket::curve_server(false));
        subscriber->set_option(azmq::socket::curve_publickey(client_public_key, 40));
        subscriber->set_option(azmq::socket::curve_privatekey(client_secret_key, 40));
        subscriber->set_option(azmq::socket::curve_serverkey(server_key.data(), server_key.size()));        

    subscriber->connect("tcp://exampleserver.com:11000");
    subscriber->async_receive_more(boost::asio::buffer(buffer), message_received);

    ios.run();

    return 0;
}

I could be missing something, but if I use receive/async_receive with a MutableBufferSequence to read variable-sized multipart messages, nothing is returned that tells me the size of each buffer or the number of parts received. The callback returns total bytes received, but that's not enough to determine part sizes.

To address this I went through an added a "MutableSizes" template parameter to receive_buffer_op and receive_more_buffer_op, set sizes in receive(MutableBufferSequence) and returned number of parts. I can submit a pull request if this is useful, or is there a more elegant way to accomplish this?

Header-only library is much simple to use because no build needed (so no recompilation needed when C++ compiler or Boost version need to be changed) so it worth to switch to it.

API supports them, but not currently exposed

Using of router_socket (ZMQ_ROUTER socket type in terms of ZeroMQ) causes 100% load of one CPU core doing nothing. The problem occurs on Linux, OSX and Windows platforms.

The simplest code to reproduce the issue:

#include <boost/asio.hpp>
#include <azmq/socket.hpp>

int main()
{
    boost::asio::io_service ios;

    azmq::router_socket s(ios);
    s.bind("tcp://127.0.0.1:9876");

    s.async_receive([](const boost::system::error_code & ec, azmq::message & msg, size_t bytes_transferred) {
    });

    ios.run();

    return 0;
}

That's it: no client need to be connected, no actual actions need to be done.

ZeroMQ version 4.0.5 is used.

not reproducible on OSX

Hello! I'm having some odd problems building azmq on Windows. This may be a rookie mistake because I'm not familiar with software development in a Windows environment, but maybe someone might have some useful info on where to go from here.

I have installed the x64 build of libzmq from the ZeroMQ website.

I have tried this with and without -G"Visual Studio 12 Win64".

...\build>set ZMQ_ROOT=C:\Program Files\ZeroMQ 4.0.4
...\build>set BOOST_ROOT=C:\Program Files\boost_1_57_0
...\build>cmake .. -G"Visual Studio 12 Win64"
-- The C compiler identification is MSVC 18.0.30723.0
-- The CXX compiler identification is MSVC 18.0.30723.0
-- Check for working C compiler using: Visual Studio 12 2013 Win64
-- Check for working C compiler using: Visual Studio 12 2013 Win64 -- works
-- Detecting C compiler ABI info
-- Detecting C compiler ABI info - done
-- Check for working CXX compiler using: Visual Studio 12 2013 Win64
-- Check for working CXX compiler using: Visual Studio 12 2013 Win64 -- works
-- Detecting CXX compiler ABI info
-- Detecting CXX compiler ABI info - done
CMake Warning (dev) at CMakeLists.txt:4 (if):
  Policy CMP0054 is not set: Only interpret if() arguments as variables or
  keywords when unquoted.  Run "cmake --help-policy CMP0054" for policy
  details.  Use the cmake_policy command to set the policy and suppress this
  warning.

  Quoted variables like "MSVC" will no longer be dereferenced when the policy
  is set to NEW.  Since the policy is not set the OLD behavior will be used.
This warning is for project developers.  Use -Wno-dev to suppress it.

-- Boost version: 1.57.0
-- Found the following Boost libraries:
--   system
--   log
--   unit_test_framework
--   date_time
--   thread
--   chrono
--   regex
--   random
CMake Error at C:/Program Files (x86)/CMake/share/cmake-3.1/Modules/FindPackageHandleStandardArgs.cmake:138 (message):
  Could NOT find ZeroMQ (missing: ZeroMQ_LIBRARIES) (found suitable version
  "4.0", minimum required is "4.0")
Call Stack (most recent call first):
  C:/Program Files (x86)/CMake/share/cmake-3.1/Modules/FindPackageHandleStandardArgs.cmake:374 (_FPHSA_FAILURE_MESSAGE)
  config/FindZeroMQ.cmake:60 (find_package_handle_standard_args)
  CMakeLists.txt:37 (find_package)

Please let me know if there's any more information that would be useful. I'm idling in Freenode/zeromq as toresbe; please ask if there's anything I can contribute with.

I created a test that rapidly sends messages on the loopback interface. This test crashes unless I add a 1ms delay between messages. I tried several situations:

The messages I am sending are fairly small, around 48 bytes. This is definitely a problem in either AZMQ or ZMQ, because I've implemented pure asio async socket interfaces in the past without encountering these issues.

Key Info

sleep line in main
key header implementing send and receive
gist containing stack trace

I've implemented an AzmqFlatbuffers class to help provide google flatbuffers integration. I'm sure it needs code cleanup and perhaps some design and implementation changes, but I would be interested in contributing it if there is interest in adding this integration.

Since it does add a dependency on flatbuffers I would suggest it be explicitly included by users who wish to use it.

I tried to create a small example, based off the provided example which sends and receives over the loopback interface, but it doesn't seem to receive anything and blocks on that call. I've included a link to the example source below.

https://github.com/ahundt/robone/blob/02e8b28354ef9921304239e38b0626b943a6fd66/src/robone.cpp

Any help would be very much appreciated!

I have Linux and Windows servers with TeamCity CI deployed. Are you OK if I'll setup a build/test jobs for AsioMQ on this servers? There is a problem that I can't give anybody access to servers itself, only to TeamCity web UI where the build status can be monitored. But may be this is better than nothing. If you are OK, I'll proceed with configuring the CI.
In future I would like to add OSX server to the build "farm".

test_socket_ops.test_send_receive_inproc_msg_vect randomly failed with error Assertion !ec in void __cdecl test_send_receive_inproc_msg_vect(void)[..\..\..\test\socket_ops\main.cpp:106]

Investigation gives that test fails with errno = 11 (EAGAIN). The reason most probably because ZMQ_RCVMORE socket option is erroneously passed as a flag for zmq_msg_recv. ZeroMQ treats it as ZMQ_NOBLOCK (aka ZMQ_DONTWAIT) flag. When this flag is passed, if there is no message available, ZeroMQ doesn't wait for a message but returns immediately with EAGAIN error (see http://api.zeromq.org/2-1:zmq-recv). Note that this behavior is not documented in later versions of ZeroMQ but still supported.

Some azmq::message constructors accept const buffer and some accept mutable buffer (i.e. can not be used to construct from const buffer). The accessors of message are const except one (non-const buffer()).

I propose to change message to be constructed only from const buffer (remember that mutable buffer is convertible to const buffer) and to remove all non-const accessors, so message can not be used to modify the buffer it created from.

This change means that non-const buffer() should be removed. I never used this function in my code but I can assume that there are use cases when this function is needed. Let's discuss this use cases and find a way to satisfy them with new message design.

message's equals operator use only size of left-hand operand, so can read memory out of right-hand operand buffer.

UPD: not equals operator should be added for consistency

azmq::message has only a syntax sugar ctor to construct from std::string. Any other construction from common "buffer representation" (e.g. c-string, void ptr + size, std::array etc) needs a call of boost::asio::buffer(). This is:

• confusing: different "buffer representations" needs different syntax to construct a message from
• non-effective: when user constructs message from c-string, temporary std::string is allocated.

I propose either:

1. Remove std::string ctor
2. Add syntax sugar ctors for common "buffer representations", at least for the following ones:
   • const void * + size_t
   • c-string

Current azmq::message streaming operator writes "message{sz=%Size%}" into stream. This is not useful except for debugging use cases and IMO confusing in a real-life attempt to stream a message. I propose to remove streaming operator, so user can use its own if needed.

I'd really like to be able to use this library to get all of the great features of ASIO with another ZMQ library Zyre. The problem is Zyre uses czmq to create and manage ZMQ sockets.
Is there a way to attach a azmq socket object to an already created ZMQ socket?
Or is there a pattern that you can suggest on how to accomplish mixing these 2 libraries?

When attempting this line (as used in the README.md example), I get a compiler error:

3>..\common\zmq.cpp(28): error C2440: '<function-style-cast>' : cannot convert from 'const char [1]' to 'azmq::socket::subscribe'
3>          No constructor could take the source type, or constructor overload resolution was ambiguous
3>..\common\zmq.cpp(28): error C2780: 'boost::system::error_code azmq::socket::set_option(const Option &,boost::system::error_code &)' : expects 2 arguments - 1 provided
3>          C:\libs\azmq\azmq/socket.hpp(245) : see declaration of 'azmq::socket::set_option'

I tried my best to read the code that fails but it's too advanced for someone just starting out in C++, so I simply wanted to make sure you knew of the error and feel free to contact me if any more information or any more tests are desired.

If I invoke it as azmq::socket::subscribe("", 1), it will fail with:

detail/socket_service.hpp(269): error C2039: 'value_' : is not a member of 'azmq::opt::binary<6>'

However, if I add a void * value_ to the binary template, the code will run.

Build environment: Win 8.1, VS2013 x64, latest snapshot.

Newer versions of Asio implement an extensible async_ form that allows async operations to work with std::future, among other things.

Will require bumping the minimum version of boost to 1.56 or later

It should be possible to compile working version of aziomq on Windows platform with using of MS Visual Studio 2013 or later compiler.