ZeroMQ (libzmq 4.3.5) — feature parity

Status: complete against the six clauses of 0013 §4.7. This document is the sixth clause itself — the row-by-row table — and §10 gives the other five their verdicts.

The library is two crates: weida-zmtp, the sans-I/O ZMTP 3.1 codec whose [dependencies] is empty, and weida-zmq, the socket implementation on top of it. Neither depends on weida; a caller who wants a ZeroMQ and nothing else uses weida-zmq alone (0013 §4.3, §4.4). The standard queue, forwarder and streamer devices are weida_zmq::proxy helpers inside this library; they connect ZeroMQ sockets to ZeroMQ sockets. No crate assigns ZeroMQ socket types global weida counterparts.

1. What a row means

Three verdicts and no fourth:

• present — implemented, with the module or test that carries it named. A present row may still say where the behaviour differs, and then the difference is the row.
• refused with a reason — the configuration exists in libzmq and fails here, at configuration time, with a message naming why (0013 §4.4 item 4). Nothing is silently ignored.
• absent with a reason — not implemented and not configurable, with what is missing named.

"Partial" is not a verdict. Where something is present in part, the row says which part is missing (0013 §4.7 clause 6).

Versions every measured claim was measured against. libzmq 4.3.5, pkg-config --modversion libzmq = 4.3.5, linked against libsodium 26, reached through the zmq crate 0.9.2; and the pure-Rust zeromq crate 0.6.0. Both were run against this library over loopback TCP on 2026-09-11 (docs/research/zeromq.md §14 sources [40] and [41]). Claims about what libzmq specifies cite that sheet's section numbers, which cite libzmq's manual pages, the ZeroMQ RFCs and the zguide. Nothing in this document is inferred from a version other than those two.

2. Socket types

zmq_socket(3)'s own table is reproduced in the sheet's §4.1 with seven columns; the compatible-peers, direction, routing and mute-state rows are the ones an implementation can be held to. Here they are, with the verdict and where the behaviour lives. "Mute action" is the socket's PipeConfig, which is the one place the choice is made, and the compatible-peers row is enforced at the handshake by SocketType::accepts in the codec, called from session.rs — a socket paired with a type its table does not list is refused with ENOCOMPATPROTO rather than left to misbehave later.

Eleven of the twelve stable types are present; ZMQ_STREAM is the one stable type that is not, and its row says what a caller who wants it does not get. The eight draft types are absent as a family, for the one reason that they are draft — weida-zmtp's metadata table still parses their Socket-Type names, because a peer may announce one and a decoder that refused the name could not report the pairing refusal properly.

3. Transports

The sheet's §12 inventories libzmq's transports. tcp, ipc and inproc are present; every other name in that inventory is refused by Endpoint::parse with EPROTONOSUPPORT and the reason below, from endpoint.rs's ABSENT_TRANSPORTS table — a name it does not know at all is refused too, with "this library speaks tcp, ipc and inproc".

4. Mechanisms and authentication

One mechanism per socket, announced in the greeting and never negotiated, which is 37/ZMTP's "security in ZMTP is assertive".

5. Options

Every zmq_setsockopt and zmq_ctx_set option of the sheet's inventory, from weida-zmq's optiontable.rs, which is the code this table is generated from and which a test walks in full: 98 rows — 38 honoured, 60 refused (24 absent with what is missing named, 14 for a transport this library does not implement, 9 replaced by a weida-runtime construct, 9 libzmq DRAFT options, 4 deprecated by libzmq itself in favour of ZAP). Eleven are zmq_ctx_set, 87 zmq_setsockopt.

Read-only options are deliberately not rows: ZMQ_EVENTS, ZMQ_FD, ZMQ_LAST_ENDPOINT, ZMQ_SOCKET_LIMIT, ZMQ_MSG_T_SIZE and ZMQ_MECHANISM are zmq_getsockopt/zmq_ctx_get only, so there is no configuration-time decision to record. ZMQ_LAST_ENDPOINT is answered by Engine's own accessor; ZMQ_FD has no counterpart at all, because this library's readiness is a future rather than a descriptor.

6. Observability

zmq_socket_monitor's event set, from monitor.rs. Two renderings of one publisher: a typed stream, and the two-frame inproc:// PAIR form the Espresso recipe reads, produced by MonitorEvent::encode and read back by decode, so the octets are asserted in both directions.

Two differences, both deliberate and both visible to a reader of the wire form:

1. A failure carries a sentence, not a number. libzmq's value field holds a ZMQ_PROTOCOL_ERROR_* code for HANDSHAKE_FAILED_PROTOCOL and the ZAP status for HANDSHAKE_FAILED_AUTH; here the value field is zero for every event except CONNECT_RETRIED, and a third frame carries this library's own reason text. What is missing for a caller matching on numbers: the ZMQ_PROTOCOL_ERROR_* enumeration. What is gained is a reason a human can read in a log, which is what those events are for; the two-frame form is preserved for the events that have no reason.
2. No transport restriction by construction. libzmq's page says the monitor "supports only connection-oriented transports, that is, TCP, IPC, and TIPC". Here the events are published at the engine's lifecycle points, which are the same for every transport this library has. The tests cover tcp; a monitor on inproc is therefore [inference] rather than measured.

zmq_proxy's capture socket is the message-level half of observability and is in §7. MONITOR_CAPACITY = 1024 events per monitor, oldest dropped first — a bound libzmq does not have (§9).

7. Devices and helpers

8. Interop evidence

Both directions of clause 4, each pairing with our socket as the connecting side and as the bound side, in the ordinary test suite (no supervised process, no script to remember).

Three measured skews against zeromq 0.6.0, exercised rather than assumed: it announces a 3.0 greeting; it recognizes only the READY command name; and it sends and reads only ZMTP 2.0's one-frame subscription form. Two further disagreements were measured and recorded as that crate's behaviour rather than ours: its XPUB applies a subscription only when the application receives it, and its DEALER announces no Identity.

Four measured facts about libzmq 4.3.5, each observed in one exchange over loopback TCP and none of them stated by its documentation (sheet §13, source [41]) — three of them forced a fix on our side:

1. The greeting's as-server octet is 0 even on a socket configured as the PLAIN or CURVE server, against 24/ZMTP-PLAIN and 25/ZMTP-CURVE, and libzmq never reads the peer's octet either. Our guard was narrowed accordingly: two peers that both claim the server role are still refused, but the octet alone no longer decides.
2. Every REQ, DEALER and ROUTER socket with no ZMQ_ROUTING_ID announces an Identity property with an empty value. 37/ZMTP's identity = 0*255OCTET permits it, so an empty property is the absence of an identity; we refused it before, which failed half the matrix at the handshake.
3. A CURVE MESSAGE travels behind a message frame header, not a command frame header, although 26/CURVEZMQ calls it a command and its body is a command body — and a command-framed MESSAGE closes the connection. The handshake commands are command frames as specified, so both forms are mixed within one connection; session.rs sends and accepts the measured form.
4. Its PLAIN and CURVE servers refuse every connection without a ZAP handler bound on inproc://zeromq.zap.01 in the same context — which 27/ZAP's "the handler SHALL start before any server starts" requires but no libzmq page states as a refusal.

Clause 5's evidence is examples/ with tests/zguide_*.rs: nine recipes — lazy, simple and paranoid pirate, the load-balancing broker inside Simple Pirate, Majordomo with mmi.service, Freelance models one and two, Clone/CHP, Binary Star, the last-value cache and Espresso — each asserting the guarantee its original claims, with the test files including the example files as modules so that what is asserted is the code a reader runs.

9. Deliberate deviations and bounds libzmq does not have

Two deliberate default changes (0013 §4.4 item 5), both settable back to anything the type allows and both rows in §5:

One behavioural difference found by a test rather than by reading: ZMQ_LINGER maps to the context's close budget at Context::shutdown and not to socket drop, so a socket dropped before its session flushed loses its queued messages. Found by the blocking facade's first REQ/REP test, and the reason its hello_world example loops like hwserver.c instead of returning.

Two errnos libzmq has no name for, because it has nowhere to report them: EACCES for a peer a ZAP handler refused, and ENOCOMPATPROTO for a dialog that malfunctioned — a peer announcing a mechanism or socket type this side cannot pair with, or a malformed handshake.

One API libzmq does not have, because C does not need it: split(self) on DEALER, ROUTER, PAIR, XPUB and XSUB, returning a sending and a receiving half onto the same connections. libzmq's socket is a pointer any thread may use one at a time; a Rust socket is a Send, non-Sync handle, and one task parked in recv() would otherwise hold the whole socket — so the concurrency libzmq permits needed a type to say it (B-177). REQ and REP have no split: 28/REQREP alternates, so two independent halves would promise what the protocol forbids. Each half is still one operation at a time, and a ROUTER's two halves share one routing table behind a lock that is never held across an await.

Seven bounds that are not libzmq options at all. libzmq bounds a message count per queue and nothing else; every number below exists because no remote input may cause unbounded allocation (INVARIANTS.md), and each is a named constant rather than a magic value:

INPROC_BUFFER_BYTES (64 KiB) and DEFAULT_MAX_RESOLVED_ADDRESSES (8) are the same kind of number for the inproc transport and the resolver.

One capability libzmq's API does not have. XPubSocket::refuse sends 37/ZMTP's ERROR command to the subscriber whose subscription arrived last, and Pipe::refuse is the channel underneath it. The protocol has always had the command — "the peer SHALL treat an incoming ERROR command as fatal" — and libzmq's API exposes no way to send one: an XPUB application can decline to apply a subscription (ZMQ_XPUB_MANUAL) and cannot say why. That silence is unusable for an adapter, because a subscription silently ignored is a subscriber waiting forever for messages nobody will send, so this library has the command and the row is here rather than hidden. It is additive: nothing sends an ERROR unless an application asks, and the connection is left to the peer's own rule.

What replaces an option rather than refusing it. Nine rows of §5 are RuntimeInstead: libzmq's I/O-thread pool, thread affinity, priority, scheduling policy and name prefix are a Tokio runtime here, sized by ContextConfig::worker_threads, and ZMQ_BLOCKY has nothing to switch off because the close budget is already finite.

10. The definition of done

0013 §4.7's six clauses, each with its verdict and where this document proves it.

What a caller who compares this library with libzmq 4.3.5 does not get, in one list: ZMQ_STREAM; the draft socket families and their transports; GSSAPI; the multicast, datagram, WebSocket, hypervisor and cluster transports; ZMQ_PROTOCOL_ERROR_* numbers in monitor events ; a descriptor-based poller; and every option §5 marks refused. Nothing else.

11. Sources

• ../research/zeromq.md — §2 (context, monitor, proxy), §4.1 (the socket-type tables), §4.2-§4.6 (the pattern RFCs and the draft families), §5 (flow control and the mute state), §9 (the zguide recipes), §10 (security, ZAP, the CURVE octet counts), §11 (options and limits), §12 (transports), §13 (the measured libzmq and zmq.rs facts), §14 sources [17], [18], [22], [23], [40], [41].
• 0013 §4.1 (crate layout), §4.3 (weida-zmtp stays sans-I/O), §4.4 (the shape of weida-zmq, the option rule and the two default changes), §4.7 (the six clauses), §5.5 (the kind column).
• INVARIANTS.md — the allocation invariant §9's bounds answer.
• Code the verdicts were read from, all under crates/zmq/weida-zmq/src/: optiontable.rs (§5, generated from OPTIONS), endpoint.rs (§3), options.rs and curve.rs and zap.rs (§4), reqrep.rs, dealerrouter.rs, pubsub.rs, xpubxsub.rs, pipeline.rs, pair.rs (§2), monitor.rs (§6), proxy.rs (§7), session.rs (the handshake refusals), plus tests/interop_zmqrs.rs, tests/interop_libzmq.rs and tests/zguide_*.rs (§8).