* Feature: integrate libzmq with ReadTheDocs
* add readthedocs configuration file to convert Asciidoc files into HTML and HTMLZIP formats using Asciidoctor.js tool (the only Asciidoctor variant available on readthedocs so far)
* migrate from the old, unmaintained "asciidoc-py" tool to the new "asciidoctor" generator
* migrate from asciidoc-py syntax to the modern Asciidoc syntax (especially page titles and section titles)
* remove the need of "xmlto" utility to create the manpage output; use asciidoctor for that
* add HTML output support to the doc/Makefile by using asciidoctor
* change API documentation files extension from .txt to .adoc to make it more explicit that they are Asciidoc-encoded (as a bonus several IDE plugins will autodetect the .adoc format as Asciidoc)
* remove asciidoc.conf: asciidoctor does not support that; this also required replacing the macro linkzmq into all documentation pages
* add a new Github action CI do deploy to Github Pages the static HTMLs produced by Asciidoctors
* removed references to the "xmlto" and "a2x" tools from the build and packaging systems: Asciidoctor can convert the documentation directly to e.g. pdf (via extended converters) and anyway there was no code/target for using "xmlto" and "a2x" tools anyway
Problem: reimplemented zmq_proxy_steerable control socket type is not
backwards compatible - replies are always sent.
In the past, zmq_proxy_steerable never sent a reply for
commands that weren't STATISTICS, so only really worked with PAIR and didn't
work at all with REP. Now it only supports REP and PAIR semantics changed. This
breaks compatibility with PAIR in a subtle and slightly annoying way if
HWMs are hit without reading the replies.
Solution: Add a check to send the empty reply only for
REP control sockets. This restores backwards compatibility, and supports
REP, PAIR, and SUB (for non-reply commands).
I had no knowledge of the pre-MPL-2.0 implementation. This fix is based
on docs and prior API usage. I contribute this under MPL-2.0.
It is contriubted under the MPL-2.0.
I had no knowledge of the previous implementation of zmq_proxy_steerable().
This version was developed based on expectations set in the old man page with one exception. This version uses a REP/REQ for the proxy control protocol sockets. The old man page example used PUB/SUB which is nonsensical given the STATISTICS command requires two way communication.
Solution: remove the implementation. Thijs Terlouw <thijsterlouw@gmail.com>,
the author, did not respond to requests to allow relicensing to MPL2,
so we have to remove his copyrighted work.
Remove the implementation and make get/set return -EOPNOTSUPP.
Solution: remove implementation. Laurent Alebarde <l.alebarde@free.fr>,
the author, did not respond to requests to allow relicensing to MPL2,
so we have to remove his copyrighted work.
Make the API into an empty stub that returns -EOPNOTSUPP.
Solution: Replace incorrect underline pattern in zmq_udp.txt that
makes part of the text show up as pre-formatted code block with
regular underline pattern.
zmq_ppoll mostly mimics zmq_poll behavior, except for the added feature of being able to specify a signal mask. Signals in this mask will be blocked during execution of zmq_ppoll. Switching of the process' active signal mask happens atomically with the actual poll call, so that no race conditions can occur. This behavior is useful when one wants to gracefully handle POSIX signals without race conditions. See e.g. the discussion below https://250bpm.com/blog:12/ for an explanation.
Also includes two new tests:
1. test_zmq_ppoll_fd does the same thing as test_zmq_poll_fd, demonstrating backwards compatibility with zmq_poll when used with a default signal mask.
2. test_zmq_ppoll_signals demonstrates the use of zmq_ppoll with a signal mask, blocking out SIGTERM everywhere except in zmq_ppoll, allowing to handle the signal in one place without having to worry about race conditions.
This is important in order to send the login sequence of a client to the server.
Solution: add ZMQ_HICCUP_MSG to a socket, socket would send that message whenever a connection get temporarly disconnected
* Problem: No direct support for setting socket priority
Solution: Add ZMQ_PRIORITY socket option, which sets the
SO_PRIORITY socket option on the underlying socket. This
socket option is not supported under Windows. Check option
and set socket option on creation of underlying socket.
Fixed three things:
1. Moved asterisks by variable names into the single quotes (to match [zmq_poll](https://github.com/zeromq/libzmq/edit/master/doc/zmq_init.txt) and other pages.)
2. Fixed variable name in example.
3. Fixed extra & in example.
ZMQ_ROUTER_NOTIFY doesn't have a context and doesn't play nice with protocols. with ZMQ_DISCONNECT_MSG we can set it to a protocol message, like DISCONNECT in majordomo. Router will send it when a peer is disconnected. Another advantage of ZMQ_DISCONNECT_MSG is that it also works on inproc.
Together with ZMQ_HEARTBEAT it allows to build very reliable protocols, and much simpler as well.
When using ZMQ_HEARTBEAT one still needs to implement application-level heartbeat in order to know when to send a hello message.
For example, with the majordomo protocol, the worker needs to send a READY message when connecting to a broker. If the connection to the broker drops, and the heartbeat recognizes it the worker won't know about it and won't send the READY msg.
To solve that, the majordomo worker still has to implement heartbeat. With this new option, whenever the connection drops and reconnects the hello message will be sent, greatly simplify the majordomo protocol, as now READY and HEARTBEAT can be handled by zeromq.
* UDP is mentioned as available transport, and it also supports
wildcard addresses, but not mentioned
* zmq_unbind(7) also mentions about wild-card endpoint in zmq_bind(3)
Solution: add udp in wildcard address related docs
Solution: a new socket type, called PEER. Very similar to SERVER, but can only connect to other PEERs. Also a new zmq_connect_peer method, that connect and return a routing-id in thread-safe and atomic operation
Solution: fix handling of _starting and _terminate flags
Add tests for this situation.
Clarify documentation of zmq_ctx_shutdown and zmq_socket.
Fixes#3792
Solution: now if the first frame in a multipart message is not subscribe/unsubscribe,
the rest of the parts are also considered to be not subscribe/unsubscribe.
Solution: Reflect real behavior of sockets blocking on send operations
Sockets that block in mute state only block when no peer is available if
the transport is connection-oriented and the ZMQ_IMMEDIATE socket option
is set.
Solution: restore separate zmq_unbind documentation, adding a note that the implementation
might be shared but the semantics are different and should not be mixed.
This avoids tying the API to the implementation details which might change for some
engines.
Solution: clearly advise users to avoid them in all cases to
avoid unforseen problems.
Also fix markdown syntax, applicable transport types and getter description.
Make it explicit that the two functions are identical.
Also document the expected disconnect behavior extensively
and illustrate the difference between disconnecting a
connected vs. bound endpoint.
Solution: Include a new section on configuring both ZMQ and the host
OS tx/rx buffers to facilitate sending large messages at a high data
rate with the PGM protocol.
* Add ZMQ_XPUB_MANUAL_LAST_VALUE
* Surpport xpub send last value caching to one pipe with ZMQ_XPUB_MANUAL_LAST_VALUE
* Add test_xpubub_manual_last_value
* Add relicense and doc
Solution: Allow ZMQ_PUB and ZMQ_PUSH sockets types for the monitoring.
This way someone could create a ZMQ_PULL socket connected to multiple
monitoring sockets at the same time.
Solution: add space between OR'ed values
zmq_getsockopt.3 2472: warning [p 17, 9.5i, div '3tbd1,1', 0.5i]: can't break line
zmq_setsockopt.3 3471: warning [p 24, 1.8i, div '3tbd1,1', 0.5i]: can't break line
Solution: add API and ZMQ_EVENT_PIPES_STATS event which generates 2
values, one for the egress and one for the ingress pipes respectively.
Refactor the events code to be able to send multiple values.
Solution: mark test_rebind_ipc as XFAIL on Hurd as it does not
implement getsockname on IPC and thus it's impossible to use
wildcard IPC binds.
Document that ZMQ_LAST_ENDPOINT does not work on Hurd with IPC.
Solution: remove documents and tests for ZMQ_THREAD_PRIORITY getter. It
never worked and can never work as it has the same value as a get-only
option ZMQ_SOCKET_LIMIT. It cannot be changed without breaking ABI.
Note that the setter works fine as ZMQ_SOCKET_LIMIT is get-only.
