aboutsummaryrefslogtreecommitdiff
path: root/doc/zmq.md
diff options
context:
space:
mode:
authorJohnathan Corgan <johnathan@corganlabs.com>2015-09-29 10:48:45 -0700
committerJohnathan Corgan <johnathan@corganlabs.com>2015-09-29 10:48:45 -0700
commitab0b8be8579d6a8fca26ac9ee7f2cffbca8d72e9 (patch)
tree67b153edf31184b736b48a4820bafbb31709f116 /doc/zmq.md
parent6cebd5d854b2eda9ccfb403e9e73ee2b7fea18fb (diff)
zmq: update and cleanup build-unix, release-notes, and zmq docs
Signed-off-by: Johnathan Corgan <johnathan@corganlabs.com>
Diffstat (limited to 'doc/zmq.md')
-rw-r--r--doc/zmq.md53
1 files changed, 28 insertions, 25 deletions
diff --git a/doc/zmq.md b/doc/zmq.md
index fd04f6d9f0..358d29d046 100644
--- a/doc/zmq.md
+++ b/doc/zmq.md
@@ -1,7 +1,7 @@
# Block and Transaction Broadcasting With ZeroMQ
[ZeroMQ](http://zeromq.org/) is a lightweight wrapper around TCP
-connections, inter-process communications, and shared-memory,
+connections, inter-process communication, and shared-memory,
providing various message-oriented semantics such as publish/subcribe,
request/reply, and push/pull.
@@ -14,17 +14,18 @@ requesting blockchain related data. However, there exists only a
limited service to notify external software of events like the arrival
of new blocks or transactions.
-The ZeroMQ facility implements a notification interface through a
-set of specific notifiers. Currently there are notifiers that publish
+The ZeroMQ facility implements a notification interface through a set
+of specific notifiers. Currently there are notifiers that publish
blocks and transactions. This read-only facility requires only the
-connection of a corresponding ZeroMQ subscriber port in receiving
+connection of a corresponding ZeroMQ subscriber port in receiving
software; it is not authenticated nor is there any two-way protocol
involvement. Therefore, subscribers should validate the received data
since it may be out of date, incomplete or even invalid.
-ZeroMQ sockets are self-connecting and self-healing; that is, connects
-made between two endpoints will be automatically restored after an
-outage, and either end may be freely started or stopped in any order.
+ZeroMQ sockets are self-connecting and self-healing; that is,
+connections made between two endpoints will be automatically restored
+after an outage, and either end may be freely started or stopped in
+any order.
Because ZeroMQ is message oriented, subscribers receive transactions
and blocks all-at-once and do not need to implement any sort of
@@ -32,13 +33,13 @@ buffering or reassembly.
## Prerequisites
-The ZeroMQ feature in Bitcoin Core uses only a very small part of the
-ZeroMQ C API, and is thus compatible with any version of ZeroMQ
-from 2.1 onward, including all versions in the 3.x and 4.x release
-series. Typically, it is packaged by distributions as something like
-*libzmq-dev*.
+The ZeroMQ feature in Bitcoin Core requires ZeroMQ API version 4.x or
+newer. Typically, it is packaged by distributions as something like
+*libzmq3-dev*. The C++ wrapper for ZeroMQ is *not* needed.
-The C++ wrapper for ZeroMQ is *not* needed.
+In order to run the example Python client scripts in contrib/ one must
+also install *python-zmq*, though this is not necessary for daemon
+operation.
## Enabling
@@ -60,17 +61,19 @@ Currently, the following notifications are supported:
-zmqpubrawblock=address
-zmqpubrawtx=address
-The socket type is PUB and the address must be a valid ZeroMQ
-socket address. The same address can be used in more than one notification.
+The socket type is PUB and the address must be a valid ZeroMQ socket
+address. The same address can be used in more than one notification.
For instance:
- $ bitcoind -zmqpubhashtx=tcp://127.0.0.1:28332 -zmqpubrawtx=ipc:///tmp/bitcoind.tx.raw
+ $ bitcoind -zmqpubhashtx=tcp://127.0.0.1:28332 \
+ -zmqpubrawtx=ipc:///tmp/bitcoind.tx.raw
Each PUB notification has a topic and body, where the header
-corresponds to the notification type. For instance, for the notification
-`-zmqpubhashtx` the topic is `hashtx` (no null terminator) and the body is the
-hexadecimal transaction hash (32 bytes).
+corresponds to the notification type. For instance, for the
+notification `-zmqpubhashtx` the topic is `hashtx` (no null
+terminator) and the body is the hexadecimal transaction hash (32
+bytes).
These options can also be provided in bitcoin.conf.
@@ -78,9 +81,9 @@ ZeroMQ endpoint specifiers for TCP (and others) are documented in the
[ZeroMQ API](http://api.zeromq.org).
Client side, then, the ZeroMQ subscriber socket must have the
-ZMQ_SUBSCRIBE option set to one or either of these prefixes (for instance, just `hash`); without
-doing so will result in no messages arriving. Please see `contrib/zmq/zmq_sub.py`
-for a working example.
+ZMQ_SUBSCRIBE option set to one or either of these prefixes (for
+instance, just `hash`); without doing so will result in no messages
+arriving. Please see `contrib/zmq/zmq_sub.py` for a working example.
## Remarks
@@ -93,6 +96,6 @@ No authentication or authorization is done on connecting clients; it
is assumed that the ZeroMQ port is exposed only to trusted entities,
using other means such as firewalling.
-Note that when the block chain tip changes, a reorganisation may occur and just
-the tip will be notified. It is up to the subscriber to retrieve the chain
-from the last known block to the new tip.
+Note that when the block chain tip changes, a reorganisation may occur
+and just the tip will be notified. It is up to the subscriber to
+retrieve the chain from the last known block to the new tip.