Solution: fix it.
The documentation first states that the ZMQ_SNDMORE flag is ignored on
data frames. Then it states that omitting the ZMQ_SNDMORE flag has
consequences. The example HTTP server code further muddies the situation
with a similar comment.
The implementation of ZMQ_STREAM only accepts two-part messages.
The first part is an identity frame while the second and last part is
the data frame.
As with any multipart message, all parts except the last need the
ZMQ_SNDMORE flag. The second and last part would normally omit the
ZMQ_SNDMORE flag to mark the end of the multipart message.
However, the ZMQ_STREAM implementation ignores the ZMQ_SNDMORE flag on
the data frame rather than requiring that it be omitted. The latter
behaviour would have been more consistent with the other ZeroMQ
sockets.
Solution: import and adapt Debian's packaging code from
https://packages.debian.org/source/unstable/zeromq3
As noted in packaging/debian/copyright, these files are licensed
under the LGPL2+ and the copyright belongs to the authors listed in
the same file.
Linux provides accept4(2) which will return a socket with FD_CLOEXEC set
when called with the SOCK_CLOEXEC flag. So call this when available and
fall back to fcntl(..., FD_CLOEXEC) if not.
getifaddrs() can fail transiently with ECONNREFUSED on Linux.
This has been observed with Linux 3.10 when multiple processes
call zmq::tcp_address_t::resolve_nic_name() simultaneously.
Before asserting in this case, make 10 attempts, with exponential
backoff, given by (1 msec * 2^i), where i is the attempt number.
Fixes#2051
only if the library is found at a specific path
Solution: Search for libzmq.lib in ../bin/Win32/Debug/v120/dynamic, don't
know how to automatically search in correct path based on current build
configuration
On Windows, the written message does not seem to be guaranteed to be
written to stderr, in particular when stderr is redirected to a file. I
suppose this is because RaiseException terminates the process in a way
that does not give the CRT a chance to flush stdio buffers (or if it
does, there might be a problem when more than one CRT instance is linked
into the program and they overwrite each other's exception handler). Either
way, just make sure the assertion message ends up written to stderr to
ease diagnostics.
Solution: Provide poll() for Windows as well. This is a build option that
defaults to off as the resulting binary will only run on Windows Vista or
newer.
This is not tested with alternative Winsock service providers like VMCI,
but the documentation for WSAPoll does not mention limitations.
On my local machine, throughput improves by ~10 % (20 simultaneous
remote_thr workes to one local_thr, 10 byte messages), while latency
improves by ~30 % (measured with remote/local_lat).
