search

bitcoin / bitcoin

Bitcoin Core integration/staging tree
https://bitcoincore.org/en/download
MIT License
78.48k stars 36.18k forks source link

Make it possible to get zmq notification URIs through RPC #7760

Closed laanwj closed 6 years ago

laanwj commented 8 years ago

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.

jonasschnelli commented 8 years ago

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

laanwj commented 8 years ago

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.

dcousens commented 8 years ago

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)

promag commented 8 years ago

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.

laanwj commented 8 years ago

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.

promag commented 8 years ago

@laanwj maybe zmqpubaddress=address and zmqpubtypes=rawtx,hashtx,rawblock,hashblock,mempool whatever.

laanwj commented 8 years ago

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.