Bitcoin Forum

Hi,

I have been waiting for this feature forever and I'm really interested to connect to a remote ArmoryDB.

I'm trying to launch it with --armorydb-ip=192.168.2.32 or --armorydb-ip="192.168.2.32" or pretty much every possible combination but it always throws an error in ArmoryQT.exe.log. Here it is. --armorydb-port throws the same error if I specify it.

Traceback (most recent call last):
  File "ArmoryQt.py", line 44, in <module>
  File "armoryengine\ALL.pyc", line 10, in <module>
  File "armoryengine\BDM.pyc", line 372, in <module>
  File "armoryengine\BDM.pyc", line 158, in __init__
  File "armoryengine\BDM.pyc", line 173, in instantiateBDV
TypeError: in method 'BlockDataViewer_getNewBDV', argument 1 of type 'string const &'

Did you put your ArmoryDB behind an http daemon?

No? I thought it was only required for many client. I might have misunderstood the release notes.

Will put behing nginx and report back.

More of the same.

I get some kind of hex number on 192.168.2.32:80 showing the HTTP daemon is working I guess but ArmoryQT is still throwing the same error.

EDIT: After looking through the forum, I found this which is the exact same setup I have but nginx is listening on port 80 instead of 9002. https://bitcointalk.org/index.php?topic=1617087.20

I guess this is an unresolved bug? Will try to run ArmoryQT from a Linux VM tonight as this guy seem to say that it works from Linux ArmoryQT to a Linux ArmoryDB/nginx/bitcoind setup.

His issue was specifically *nix server to Windows client


DB only has a fcgi layer (this is what PHP uses, as an example). You need consider the DB as something like a MySQL server. It isn't meant to be exposed to the WAN directly, nor an insecure LAN, because it does not have the necessary code to allow users to setup networking rules nor load balancing. That's what the public facing daemons are for.

The DB is hardcoded to listen to localhost. You can change the FCGI listen port but not the IP. You need to run the daemon in front of it to allow clients to access it remotely.

Since this is FCGI, the client uses HTTP over the socket, which is why it is fairly easy to setup a daemon on top of it (and one of the advantages of CGI in general).

As a convenience feature, I also implemented FCGI at the client level, so that it may speak with a local DB without the need for the HTTP daemon in between.

The client will only speak FCGI if you let it run the default IP:port to connect to the DB. If you change any of those, it will revert to pure HTTP, which the expected daemon on the other side will convert to FCGI for the server's benefit. The server only speaks FCGI (which basically decorates HTTP packets with some meta data).


Your best course of action is to participate to the 0.96 testing rounds to help me isolate and fix any bug on that front.

Will do!