Topic: Electrum server discussion thread - page 16. (Read 61507 times)
Electrum server made great progress. I'm running latest version on electrum.bitcoin.cz for few days and everything works perfectly, plus RAM requirement dropped to half...
time is a ping time. the client sends a ping every minute. there is no timeout server side atm.
Ah, I thought "time" would be "cpu time".
Then they heavy load on the system it was just coincidence.
Btw, the new "leveldb" backend is just great. Nice work!
ThomasV, a few questions:
First, could you explain what the column "sub" represents?
Second, any idea about tha last line? What is that?
And last - see the time value on the second line? I have such clients on a regular basis. Sometimes multiple at once. Any chance to limit the resources for a single client?
Code:
./server.py info
type address sub version time
TCP280 1.5 6.89
TCP6 1.4 40529.56
TCP7 1.4 9.17
TCP9 1.4 9.19
TCP0 unknown 0.00
First, could you explain what the column "sub" represents?
Second, any idea about tha last line? What is that?
And last - see the time value on the second line? I have such clients on a regular basis. Sometimes multiple at once. Any chance to limit the resources for a single client?
sub = number of subscriptions
last line = the connection you make when you run the 'info' command
time is a ping time. the client sends a ping every minute. there is no timeout server side atm.
ThomasV, a few questions:
First, could you explain what the column "sub" represents?
Second, any idea about tha last line? What is that?
And last - see the time value on the second line? I have such clients on a regular basis. Sometimes multiple at once. Any chance to limit the resources for a single client?
Code:
./server.py info
type address sub version time
TCP280 1.5 6.89
TCP6 1.4 40529.56
TCP7 1.4 9.17
TCP9 1.4 9.19
TCP0 unknown 0.00
First, could you explain what the column "sub" represents?
Second, any idea about tha last line? What is that?
And last - see the time value on the second line? I have such clients on a regular basis. Sometimes multiple at once. Any chance to limit the resources for a single client?
I'm still playing with this with my local VMs.
Hopefully I'll have a real server soon.
Hopefully I'll have a real server soon.
we now have two pruning servers up and running:
ecdsa.org and electrum.novit.ro
if you restore your wallet from seed on one of those servers, your history will be pruned.
the 1.4 client does not display correctly the pruned history, but the version of the client in github does.
I will make a new release soon, to include this change.
ecdsa.org and electrum.novit.ro
if you restore your wallet from seed on one of those servers, your history will be pruned.
the 1.4 client does not display correctly the pruned history, but the version of the client in github does.
I will make a new release soon, to include this change.
I'll test this the moment it's out! No libbitcoin or Abe?
no libbitcoin, no abe
you can already test it, it is in the repo.
you need to 'backend=bitcoind' to your configuration file, and to update it frequently, because I am still making changes to it
Is the HOWTO located below still accurate?
https://gitorious.org/electrum/server/blobs/master/HOWTO
Thanks.
https://gitorious.org/electrum/server/blobs/master/HOWTO
Thanks.
not really.
the best source of feedback is IRC
I have been working on a new sever backend, that uses only bitcoind and not Abe.
it is almost ready. I'll catch up with the docs after that
Is the HOWTO located below still accurate?
https://gitorious.org/electrum/server/blobs/master/HOWTO
Thanks.
https://gitorious.org/electrum/server/blobs/master/HOWTO
Thanks.
not really.
the best source of feedback is IRC
I have been working on a new sever backend, that uses only bitcoind and not Abe.
it is almost ready. I'll catch up with the docs after that
Is the HOWTO located below still accurate?
https://gitorious.org/electrum/server/blobs/master/HOWTO
Thanks.
https://gitorious.org/electrum/server/blobs/master/HOWTO
Thanks.
I pushed another server update: version 0.5
This version requires the latest version of bitcoind (currently in git head), compiled with a new patch that is in the directory "patch"
This new protocol sends serialized transactions directly to the client, and will be required by electrum 1.3 clients.
So, please update your servers; I know it is a pain to have to patch bitcoind again, but this is necessary for spv.
This version requires the latest version of bitcoind (currently in git head), compiled with a new patch that is in the directory "patch"
This new protocol sends serialized transactions directly to the client, and will be required by electrum 1.3 clients.
So, please update your servers; I know it is a pain to have to patch bitcoind again, but this is necessary for spv.
Today I updated the server source again, with a slight modification of the protocol (spv-related calls)
The current version of the protocol is 0.4 (visible in your server's irc "real name")
Please upgrade your server if you have not done so.
The current version of the protocol is 0.4 (visible in your server's irc "real name")
Please upgrade your server if you have not done so.
I updated uncle-enzo.mit.edu to the latest version of the server. I can't connect using TCP/SSL, though. Port 50002 is open, but I still get the "Failed to connect uncle-enzo.mit.edu:50002" message when I try to connect. I'm using a self-signed certificate, would that cause problems?
no, you can use a self-signed certificate
I updated uncle-enzo.mit.edu to the latest version of the server. I can't connect using TCP/SSL, though. Port 50002 is open, but I still get the "Failed to connect uncle-enzo.mit.edu:50002" message when I try to connect. I'm using a self-signed certificate, would that cause problems?
Thomas, what is wrong with getrawmempool in 0.7.0 ? On my server (renamed from california.stratum.bitcoin.cz to electrum.bitcoin.cz because of IRC limitation in name length), I'm using "getrawmempool" with 0.7.1 without any (obvious?) issues.
Btw thanks to my server update, electrum.bitcoin.cz now supports SSL!
Btw thanks to my server update, electrum.bitcoin.cz now supports SSL!
Confirmed, I'm now connected through SSL (using client 1.1)
Great stuff![EDIT] It seems the client is briefly losing its connection every minute or so (then spontaneously reconnects after a few seconds.) I'm also getting this error message in the console:
SSLError: The read operation timed out
Thomas, what is wrong with getrawmempool in 0.7.0 ? On my server (renamed from california.stratum.bitcoin.cz to electrum.bitcoin.cz because of IRC limitation in name length), I'm using "getrawmempool" with 0.7.1 without any (obvious?) issues.
Btw thanks to my server update, electrum.bitcoin.cz now supports SSL!
Btw thanks to my server update, electrum.bitcoin.cz now supports SSL!
Two server upgrades this morning:
- the protocol version is now 0.2. this indicates servers that have get_header and get_merkle
- the server now uses 'getrawmempool' (bitcoind 0.7); with this version, you do not need to patch bitcoind anymore in order to run a server.
- the protocol version is now 0.2. this indicates servers that have get_header and get_merkle
- the server now uses 'getrawmempool' (bitcoind 0.7); with this version, you do not need to patch bitcoind anymore in order to run a server.
I pushed SSL support to the repo; it will be used by the next release of the client.
if you have a server, please upgrade
if you have a server, please upgrade
So Abe on Postgre won't work with default Abe config? Maybe we should do some workaround in Electrum and expect binary data there. Converting binary data to hex isn't so hard and I bet that storing binary data in database will save lot of storage space...
The default is for binary-type to be unset. I don't know what Abe does in that case. By setting "binary-type = pg-bytea", you force Abe to use Postgresql's BYTEA storage type. Setting "binary-type = hex" does the opposite and forces Abe to use hex strings instead.
The module binascii has a function hexlify that will convert buffer objects to hex strings.
The server has been running for ~48 hours with no problems, so I'm willing to declare this problem solved. In case anyone comes across this problem in the future, setting "binary-type = hex" in abe.conf did the trick.
So Abe on Postgre won't work with default Abe config? Maybe we should do some workaround in Electrum and expect binary data there. Converting binary data to hex isn't so hard and I bet that storing binary data in database will save lot of storage space...
Jump to: