zmqpubhashblock paramter, only the first one will be used. Therefore a user may be forced to listen on all interfaces (e.g. zmqpubhashblock=0.0.0.0:28332), which can result in an increased attack surface.
With this PR a user can specify multiple interfaces to listen on, e.g.
-zmqpubhashblock=tcp://127.0.0.1:28332 -zmqpubhashblock=tcp://192.168.1.123:28332.
The following sections might be updated with supplementary metadata relevant to reviewers and maintainers.
No conflicts as of last run.
Concept ACK.
Maybe use a minimal diff
0 for (const auto& entry : factories)
1 {
2 std::string arg("-zmq" + entry.first);
3- if (gArgs.IsArgSet(arg))
4- {
5- CZMQNotifierFactory factory = entry.second;
6- std::string address = gArgs.GetArg(arg, "");
7+ CZMQNotifierFactory factory = entry.second;
8+ for (const std::string& address : gArgs.GetArgs(arg)) {
9 CZMQAbstractNotifier *notifier = factory();
10 notifier->SetType(entry.first);
11 notifier->SetAddress(address);
Also:
Welcome!
- update some test in test/functional/interface_zmq.py with multiple interfaces. @n-thumann don’t forget about this.
- update some test in test/functional/interface_zmq.py with multiple interfaces.
@n-thumann don’t forget about this.
Thank you for your feedback! The test is already in the works :)
debug.log prints
2020-03-11T17:52:01.715152Z [scheduler] zmq: Publish hashblock <blockhash>
2020-03-11T17:52:01.715248Z [scheduler] zmq: Publish hashblock <blockhash>, when hashblock is triggered and ZeroMQ is listening on two interfaces.
Do you think it´s useful to append something like to tcp://127.0.0.1:28332 to each log entry, so that a user knows why there is an apparently duplicate entry?
Do you think it´s useful to append something like
to tcp://127.0.0.1:28332to each log entry, so that a user knows why there is an apparently duplicate entry?
Yes, makes sense in this change. Alternatively it could avoid printing the duplicate messages but not worth it.
47@@ -48,6 +48,7 @@ def run_test(self):
48 try:
49 self.test_basic()
50 self.test_reorg()
51+ self.test_multiple_interfaces();
0test/functional/interface_zmq.py:51:44: E703 statement ends with a semicolon
1^---- failure generated from test/lint/lint-python.sh
Tested ACK
I tested on Ubuntu 19.10 x86_64 with zmq version 4.3.2.
I verified that the node starts when not specifying any of the zmq flags, when starting with between 1 and 3 -zmqpubhashblock on different addresses and/or ports, with and without -zmqpubhashblockhwm=10000. I verified log entries, and I also verified receiving messages with the contrib/zmq/zmq_sub.py subscriber.
@n-thumann side note, you might have the right skill set to review my #14687 related to zmq, if you have some spare cycles. that’s a small change that the lightning guys have been requesting for a while. thanks!
216+ socket.set(zmq.RCVTIMEO, 60000)
217+ hashblock = ZMQSubscriber(socket, b"hashblock")
218+ socket.connect(address)
219+ subscribers.append({'address': address, 'socket': socket, 'hashblock': hashblock})
220+
221+ self.restart_node(0, ['-zmqpub%s=%s' % (subscribers[0]['hashblock'].topic.decode(), subscribers[0]['address']),
maybe compress this into:
self.restart_node(0, ['-zmqpub%s=%s' % (subscribers[i]['hashblock'].topic.decode(), subscribers[i]['address']) for i in range(2)])
or there-about(didn’t check parenthesis lining up :) )
utACK https://github.com/bitcoin/bitcoin/pull/18309/commits/6b8d300d2560daa80d6575cb047588aec76aa5dc
Small, straight forward change. We can clean up log messages later if they’re confusing.
