I think this'd make sense.
Currently if we have a program that uses both RPC and ZMQ we have to provide both endpoints on the command line:
./mempoolmon.py --rpc-uri=http://bitcoinrpc:user@pass:8332/ --zmq-uri=tcp://127.0.0.1:28332
Maybe a RPC call getzmqinfo. The zmq 'module' could register it itself now after #7307.
Agree that this would be useful. The original ZMQ PR had a RPC call to – at least – get the zmq urls: https://github.com/bitcoin/bitcoin/pull/5303/files#diff-c280aeb34f6d470bfb6d60c167414d4fR157
The zmq urls are what is primarily interesting. Not sure what other info to include.
I already had the feeling this was not a novel idea. Though apparently it somehow got lost :hamster: so it's good to have an issue open.
Couldn't that just be --node=127.0.0.1 and then the relevant end points can be derived? (with options for custom ports if necessary)
Though apparently it somehow got lost
My bad..
Instead of querying the url configured at command line, the client could request the start of notification and specify the url.
Couldn't that just be --node=127.0.0.1 and then the relevant end points can be derived? (with options for custom ports if necessary)
The user could be overriding them. There's an option per end-point.
I think it's bad practice to depend on default settings ("guess") for more than one thing used to find the instance. Such information should be available for query from there on.
Instead of querying the url configured at command line, the client could request the start of notification and specify the url.
Well, yes, that'd be an option. But zmq already has subscribe/unsubscribe logic of itself. I don't like adding another, mandatory, layer at the bitcoind side. The user can just configure zmq once in bitcoin.conf and then applications can use it.
In any case that would be the symmetric option "configure zmq endpoints through RPC". Not opposed to that, but for this purpose I'd just like to query already-configured ones. See #7289 if you're interested in configuring things through RPC.
BTW I'd personally like an option -zmqpuball=<endpoint> that configures all notification types to the same endpoint. The reason that this doesn't exist is that some notifications are expensive (I think actually only the full block one, which reads a block from disk and re-serializes it) which is a waste if no one is listening.
Possibly. I don't know enough about zmq usage in practice to be sure what @jmcorgan's original motivation was to make it possible to have multiple zmq endpoints for different notifications. I suppose it offers some extra flexibility.
I don't see a strong reason to change the current argument format in short notice though.