Two instances one computer

[mizerydearia]

I'm running two instances on one computer in same o/s environment, one instance per system user, and thus separate ~/.bitcoin directories.

One instance is caught up with generated blocks and the other is catching up.  The instance that is caught up is a self-compiled port modified (8339) version.

I tried running the catchup one using `./bitcoin -connect 127.0.0.1:8339` and it eventually connected to the other running instance, but block additions are rather slow; about the same speed as using p2p network.  I wonder why this is.  I would imagine a lan connection or even a local connection would be practically instantaneous.

update: Strange.  I specifically `./bitcoin -connect 127.0.0.1:8339`ed and the client has 3 connections?  I thought it didn't use p2p network when -connect argument was specified.  Perhaps then, the 1 connection that was, wasn't a connection to myself

[1714965346]

1714965346

[1714965346]

1714965346

[1714965346]

1714965346

[Strofcon]

I may be way wrong, but if you recompiled the client to use port 8339, and you're telling the modified client to connect only to localhost:8339... wouldn't that gain you very little? In other words, I'd think it would be redundant... You may want to try connecting to localhost:8333 instead...? I'm not sure, but it can't hurt! :-)

[dete]

I'm not sure why you want to run two instances on one computer, but I can answer your question:

For some reason (and I have no idea why!), PROCESSING the downloaded blocks from the swarm is slow.  Validating the blocks shouldn't be too slow, but if you have some way of checking, you'll see that the node that is downloading blocks is slamming the disk.

Without actually profiling the software, I can't say why, but I believe you should just be able to copy the block DB (blk*.dat) from one instance to the other without any badness happening.  Just be careful not to blow away your wallet!

[mizerydearia]

I may be way wrong, but if you recompiled the client to use port 8339, and you're telling the modified client to connect only to localhost:8339... wouldn't that gain you very little? In other words, I'd think it would be redundant... You may want to try connecting to localhost:8333 instead...? I'm not sure, but it can't hurt! :-)

I tried running the nonmodified client that uses port 8333 to connect to the modified client that uses port 8339.

I'm not sure why you want to run two instances on one computer, but I can answer your question:

Initially I was unable to use Bitcoin on my computer using native linux client due to not having correct versions of libraries.  I was able to get windows client to work with Wine, but occasionally it would crash.  During usage of Bitcoin with Wine I had visited https://freebitcoins.appspot.com to request five free bitcoins from Gavin.  However, due to many crashes I never caught up in generated blocks and didn't notice the bitcoins to appear in transaction history

Eventually I have installed latest versions of libraries in my system and was able to run a native linux client.  However, I didn't immediately use the Bitcoin configuration, database or wallet files from the windows version run from Wine.  Eventually I successfully compiled a version of Bitcoin to use different ports so that I could use it with my previous/initial configuration files.  That was my initial intention for running two instances and I mistakenly ran both as the same user.

However, even though it may seem strange to run two instances of Bitcoin, both compiled to use different ports, perhaps there could be implemented a safeguard to prevent database access if it is currently in use, access or locked?  Maybe create a lock file in /var/lock?  This could prevent database corruption if a user were to run two instances of Bitcoin as same user.  Currently attempting to do so with same client or a client that uses same port seems to fail nicely due to port being used.  This concept should be applied to failing nicely if same database is being used also.

[lachesis]

I think the fixed port solution was just a stopgap. Satoshi will eventually implement switches (or a config file - overdue) to allow you to specify the port. At that point, a cross-platform locking method for the DB would have to be found.