Matt Corallo (OP)
|
![](https://bitcointalk.org/Themes/custom1/images/post/xx.gif) |
July 17, 2015, 01:53:00 AM |
|
Pulled the latest, compiled without error on 14.04 64bit & it runs - but still getting disconnects in between bandwidth saturation with tx sizes 3404 using the eu node ![Sad](https://bitcointalk.org/Smileys/default/sad.gif) Fixed server memory usage, bumped the buffer size, should work now? Nope: ...still getting flooded with large tx's all the same size too ![Sad](https://bitcointalk.org/Smileys/default/sad.gif) Whats your connection like? If you have a particularly slow downstream you may get kicked off for not keeping up (this mostly happens if you're trying to connect to a server far away from you). PM me your ip and I'll look up why you got disconnected.
|
|
|
|
kano
Legendary
Offline
Activity: 4592
Merit: 1851
Linux since 1997 RedHat 4
|
![](https://bitcointalk.org/Themes/custom1/images/post/xx.gif) |
July 17, 2015, 02:25:39 AM |
|
...
Strange, the us-west node works for me? Fixed by commenting these out: + //int v6only = 0; + //setsockopt(sock, IPPROTO_IPV6, IPV6_V6ONLY, (char *)&v6only, sizeof(v6only));
I've no idea why it fails the remote connection on my server ...
|
|
|
|
Matt Corallo (OP)
|
![](https://bitcointalk.org/Themes/custom1/images/post/xx.gif) |
July 17, 2015, 02:41:21 AM |
|
Fixed by commenting these out: + //int v6only = 0; + //setsockopt(sock, IPPROTO_IPV6, IPV6_V6ONLY, (char *)&v6only, sizeof(v6only));
I've no idea why it fails the remote connection on my server ... Huh, what OS/libc are you on?
|
|
|
|
Matt Corallo (OP)
|
![](https://bitcointalk.org/Themes/custom1/images/post/xx.gif) |
July 17, 2015, 09:10:46 PM |
|
My bitcoind server was killed by the host. The problem has now been resolved, but I'm waiting on it to sync the chain again before transactions will again be relayed within the network. See http://bitcoinrelaynetwork.org/ for latest updates.
|
|
|
|
kano
Legendary
Offline
Activity: 4592
Merit: 1851
Linux since 1997 RedHat 4
|
![](https://bitcointalk.org/Themes/custom1/images/post/xx.gif) |
July 17, 2015, 09:45:55 PM |
|
My bitcoind server was killed by the host. The problem has now been resolved, but I'm waiting on it to sync the chain again before transactions will again be relayed within the network. See http://bitcoinrelaynetwork.org/ for latest updates. Ah OK - then ignore the 2nd part of my PM ![Smiley](https://bitcointalk.org/Smileys/default/smiley.gif)
|
|
|
|
bicer
Newbie
Offline
Activity: 23
Merit: 0
|
![](https://bitcointalk.org/Themes/custom1/images/post/xx.gif) |
July 18, 2015, 01:41:32 AM |
|
Is constant "(out-of-band)" normal? Sent transaction of size 815 (out-of-band) to relay server Sent transaction of size 339 (out-of-band) to relay server Sent transaction of size 373 (out-of-band) to relay server Sent transaction of size 226 (out-of-band) to relay server
|
|
|
|
kano
Legendary
Offline
Activity: 4592
Merit: 1851
Linux since 1997 RedHat 4
|
![](https://bitcointalk.org/Themes/custom1/images/post/xx.gif) |
July 18, 2015, 02:29:10 AM |
|
Until he fixes his bitcoind. If he is re-downloading the blockchain ... that may take a loooooong while. (The advantage of running mutliple bitcoind without a wallet ... save config, wipe bad one, rsync good to bad, stop the working one, rsync good to bad again, restore the config, start them both ![Smiley](https://bitcointalk.org/Smileys/default/smiley.gif)
|
|
|
|
kano
Legendary
Offline
Activity: 4592
Merit: 1851
Linux since 1997 RedHat 4
|
![](https://bitcointalk.org/Themes/custom1/images/post/xx.gif) |
July 19, 2015, 06:37:17 AM |
|
My bitcoind server was killed by the host. The problem has now been resolved, but I'm waiting on it to sync the chain again before transactions will again be relayed within the network. See http://bitcoinrelaynetwork.org/ for latest updates. You wouldn't happen to have an ETA on this? I wrote a little script to report the tail 9999 lines of my log every 10s instead of having thousands of lines scrolling by. It still says 0 txn received.
|
|
|
|
Peter R
Legendary
Offline
Activity: 1162
Merit: 1007
|
![](https://bitcointalk.org/Themes/custom1/images/post/xx.gif) |
July 19, 2015, 04:59:28 PM |
|
Can anyone in this thread help me figure something out? I'm trying to estimate the block propagation rate using the relay network to make an apples-to-apples comparison with the 17 sec/MB figure from this TradeBlock analysis. TradeBlock's number is the average time it would take 50% of the nodes that it's watching to receive a solved block over the P2P network. Between the moment a node on the relay network has a solution to a block, how long until 50% of the entities listening on the relay network have received enough information to verify the block solution? I've seen these stats but I don't know how to interpret them.
|
|
|
|
Matt Corallo (OP)
|
![](https://bitcointalk.org/Themes/custom1/images/post/xx.gif) |
July 19, 2015, 06:35:54 PM |
|
You wouldn't happen to have an ETA on this?
Yes, it should be resolved by now.
|
|
|
|
p3yot33at3r
|
![](https://bitcointalk.org/Themes/custom1/images/post/xx.gif) |
July 19, 2015, 06:41:07 PM |
|
I'm still getting disconnects I'm afraid, but not constant as before: 127.0.0.1 Disconnect: failed to read message header (Transport endpoint is not connected) 127.0.0.1 Disconnect: failed to read message header (Transport endpoint is not connected) Received transaction of size 4027 from relay server Sent transaction of size 4027 to relay server 127.0.0.1 Disconnect: failed to read message header (Transport endpoint is not connected) 127.0.0.1 Disconnect: failed to read message header (Transport endpoint is not connected) Received transaction of size 407 from relay server Sent transaction of size 407 to relay server 127.0.0.1 Disconnect: failed to read message header (Transport endpoint is not connected) 127.0.0.1 Disconnect: failed to read message header (Transport endpoint is not connected) Received transaction of size 519 from relay server Sent transaction of size 519 to relay server Received transaction of size 1057 from relay server Sent transaction of size 1057 to relay server 127.0.0.1 Disconnect: failed to read message header (Transport endpoint is not connected) 127.0.0.1 Disconnect: failed to read message header (Transport endpoint is not connected) Received transaction of size 225 from relay server Sent transaction of size 225 to relay server Received transaction of size 225 from relay server Sent transaction of size 225 to relay server Received transaction of size 226 from relay server Sent transaction of size 226 to relay server 127.0.0.1 Disconnect: failed to read message header (Transport endpoint is not connected) 127.0.0.1 Disconnect: failed to read message header (Transport endpoint is not connected) Received transaction of size 226 from relay server Sent transaction of size 226 to relay server Received transaction of size 373 from relay server Sent transaction of size 373 to relay server Received transaction of size 226 from relay server Sent transaction of size 226 to relay server 127.0.0.1 Disconnect: failed to read message header (Transport endpoint is not connected) 127.0.0.1 Disconnect: failed to read message header (Transport endpoint is not connected)
|
|
|
|
kano
Legendary
Offline
Activity: 4592
Merit: 1851
Linux since 1997 RedHat 4
|
![](https://bitcointalk.org/Themes/custom1/images/post/xx.gif) |
July 19, 2015, 09:33:41 PM |
|
You wouldn't happen to have an ETA on this?
Yes, it should be resolved by now. Yep all the numbers looking OK again ![Smiley](https://bitcointalk.org/Smileys/default/smiley.gif) Last 9999 messages: Sent: 5752 Received: 4224
|
|
|
|
Matt Corallo (OP)
|
![](https://bitcointalk.org/Themes/custom1/images/post/xx.gif) |
July 20, 2015, 11:22:43 PM |
|
I'm still getting disconnects I'm afraid, but not constant as before:
Strange, the server logs just shows you disconnecting. Can you run Wireshark? It looks like your outbound bandwidth may be saturated by the uploading of transactions (its quite small), though I would expect your client to print errors about the buffer blowing up.
|
|
|
|
Matt Corallo (OP)
|
![](https://bitcointalk.org/Themes/custom1/images/post/xx.gif) |
July 21, 2015, 12:29:02 AM |
|
Turned on the new node in Beijing provided by f2pool and switched to a more expensive host in Tokyo which has better peering, especially into and out of China.
|
|
|
|
p3yot33at3r
|
![](https://bitcointalk.org/Themes/custom1/images/post/xx.gif) |
July 21, 2015, 08:36:52 AM |
|
I'm still getting disconnects I'm afraid, but not constant as before:
Strange, the server logs just shows you disconnecting. Can you run Wireshark? It looks like your outbound bandwidth may be saturated by the uploading of transactions (its quite small), though I would expect your client to print errors about the buffer blowing up. I can't see any reference to buffer blow-ups in the console, only the disconnects. I'll download wireshark & see what I can see. It just seems weird that these problems have only become apparent since bitcoind v11 - it ran fine previously.
|
|
|
|
Matt Corallo (OP)
|
![](https://bitcointalk.org/Themes/custom1/images/post/xx.gif) |
July 21, 2015, 08:57:07 AM |
|
I can't see any reference to buffer blow-ups in the console, only the disconnects. I'll download wireshark & see what I can see. It just seems weird that these problems have only become apparent since bitcoind v11 - it ran fine previously.
I suspect this has more to do with transaction flooding on the network and new versions of the relay network client than new versions of bitcoin.
|
|
|
|
p3yot33at3r
|
![](https://bitcointalk.org/Themes/custom1/images/post/xx.gif) |
July 21, 2015, 10:45:28 AM Last edit: July 21, 2015, 06:48:18 PM by p3yot33at3r |
|
I can't see any reference to buffer blow-ups in the console, only the disconnects. I'll download wireshark & see what I can see. It just seems weird that these problems have only become apparent since bitcoind v11 - it ran fine previously.
I suspect this has more to do with transaction flooding on the network and new versions of the relay network client than new versions of bitcoin. PM'd you ping & trace results from my router. Edit: latest release compiled without issue & running. Still getting disconnects, but far less frequent: Sent transaction of size 427 to relay server Received transaction of size 427 from relay server Sent transaction of size 427 to relay server public.eu.relay.mattcorallo.com Disconnect: failed to read message header (Transport endpoint is not connected) 127.0.0.1 Disconnect: failed to read message header (Transport endpoint is not connected) 127.0.0.1 Disconnect: failed to read message header (Transport endpoint is not connected) 127.0.0.1 Disconnect: failed to read message header (Transport endpoint is not connected) public.eu.relay.mattcorallo.com Disconnect: failed to read message header (Connection reset by peer) 127.0.0.1 Disconnect: failed to read message header (Transport endpoint is not connected) public.eu.relay.mattcorallo.com Disconnect: failed to read message header (Connection reset by peer) 127.0.0.1 Disconnect: failed to read message header (Transport endpoint is not connected) Connected to relay node with protocol version sponsor printer Received transaction of size 426 from relay server Sent transaction of size 426 to relay server Received transaction of size 426 from relay server Sent transaction of size 426 to relay server Received transaction of size 426 from relay server Sent transaction of size 426 to relay server Received transaction of size 426 from relay server Sent transaction of size 426 to relay server Received transaction of size 426 from relay server Sent transaction of size 426 to relay server Received transaction of size 426 from relay server Sent transaction of size 426 to relay server Received transaction of size 426 from relay server Sent transaction of size 426 to relay server 127.0.0.1 Disconnect: failed to read message header (Transport endpoint is not connected) Received transaction of size 426 from relay server Sent transaction of size 426 to relay server Received transaction of size 426 from relay server
The amount of Tx sizes of 226/7 & 427/8 flying by at light speed is mind blowing - never seen so many of the same size. However, what ever changes you're making seem to be an improvement, so we appear to be on the right road ![Wink](https://bitcointalk.org/Smileys/default/wink.gif) Edit2: I think I've nailed the disconnect problem. I just noticed that the default number of threads to service RPC calls is set at 4 on bitcoind, which, seeing as I'm merge mining 10 other coins plus the relaynetworkclient on my p2pool node - doesn't seem enough. So I increased this value to 10 in the .conf file using: ...and restarted bitcoind. Since doing this I've not observed a single disconnect - only the constant stream of 226/7 & 427/8 Tx fees flying by at warp speed ![Smiley](https://bitcointalk.org/Smileys/default/smiley.gif) I'll keep an eye on it, but hopefully this info will prove useful to other merge miners.
|
|
|
|
loshia
Legendary
Offline
Activity: 1610
Merit: 1000
|
![](https://bitcointalk.org/Themes/custom1/images/post/xx.gif) |
July 21, 2015, 07:03:37 PM Last edit: July 21, 2015, 07:30:10 PM by loshia |
|
p3yot33at3r, What is your isp connection? My impressions are that you are using some kind of DSL with PPPoE or dhcp. You need a static Routable ip in order to play this game. If you are behind nat your router gw is a private ip or your Routable ip changes too often that will kill your tcp connections for sure ![Wink](https://bitcointalk.org/Smileys/default/wink.gif)
If your ip is public and static you can try kano tcp6 sock hack. The above is a BULSHIT Forget it Back to your problem I do not think that dropped connections have anything in common with bitcoin rpc max threads at all. Relay client is not using RPC at all. It talks raw to btcd and relay servers Other thing to check is your BTC max peer count. I had this problem when I reached max peer connections and I have restarted relay client it would never connect. So one of the hacks to my btcd deamon is to use peer -1 and always to have a room for relay client ![Wink](https://bitcointalk.org/Smileys/default/wink.gif) I am running btcd 0.11 and relay with kano hack (because it never worked without it-thanks kano) and after block downloading again after mats incident it works just fine no issues
|
|
|
|
Matt Corallo (OP)
|
![](https://bitcointalk.org/Themes/custom1/images/post/xx.gif) |
July 21, 2015, 07:16:24 PM |
|
Sent transaction of size 427 to relay server Received transaction of size 427 from relay server Sent transaction of size 427 to relay server public.eu.relay.mattcorallo.com Disconnect: failed to read message header (Transport endpoint is not connected) 127.0.0.1 Disconnect: failed to read message header (Transport endpoint is not connected) 127.0.0.1 Disconnect: failed to read message header (Transport endpoint is not connected) 127.0.0.1 Disconnect: failed to read message header (Transport endpoint is not connected) public.eu.relay.mattcorallo.com Disconnect: failed to read message header (Connection reset by peer) 127.0.0.1 Disconnect: failed to read message header (Transport endpoint is not connected) public.eu.relay.mattcorallo.com Disconnect: failed to read message header (Connection reset by peer) 127.0.0.1 Disconnect: failed to read message header (Transport endpoint is not connected) Connected to relay node with protocol version sponsor printer Received transaction of size 426 from relay server Sent transaction of size 426 to relay server Received transaction of size 426 from relay server Sent transaction of size 426 to relay server Received transaction of size 426 from relay server Sent transaction of size 426 to relay server Received transaction of size 426 from relay server Sent transaction of size 426 to relay server Received transaction of size 426 from relay server Sent transaction of size 426 to relay server Received transaction of size 426 from relay server Sent transaction of size 426 to relay server Received transaction of size 426 from relay server Sent transaction of size 426 to relay server 127.0.0.1 Disconnect: failed to read message header (Transport endpoint is not connected) Received transaction of size 426 from relay server Sent transaction of size 426 to relay server Received transaction of size 426 from relay server
The amount of Tx sizes of 226/7 & 427/8 flying by at light speed is mind blowing - never seen so many of the same size. However, what ever changes you're making seem to be an improvement, so we appear to be on the right road ![Wink](https://bitcointalk.org/Smileys/default/wink.gif) Edit2: I think I've nailed the disconnect problem. I just noticed that the default number of threads to service RPC calls is set at 4 on bitcoind, which, seeing as I'm merge mining 10 other coins plus the relaynetworkclient on my p2pool node - doesn't seem enough. So I increased this value to 10 in the .conf file using: ...and restarted bitcoind. Since doing this I've not observed a single disconnect - only the constant stream of 226/7 & 427/8 Tx fees flying by at warp speed ![Smiley](https://bitcointalk.org/Smileys/default/smiley.gif) I'll keep an eye on it, but hopefully this info will prove useful to other merge miners. LOL, I'm blind! That is disconnecting from 127.0.0.1, so, yea, its not able to hold a connection to your bitcoind (because your bitcoind is overloaded). It has little to nothing to do with the relay network.
|
|
|
|
loshia
Legendary
Offline
Activity: 1610
Merit: 1000
|
![](https://bitcointalk.org/Themes/custom1/images/post/xx.gif) |
July 21, 2015, 07:19:28 PM |
|
Super ![Wink](https://bitcointalk.org/Smileys/default/wink.gif) Listen to Mat advise ... You need to hack your Bitcoin or to restart it while relay is running as temporally solution and pray to good it will connect ![Tongue](https://bitcointalk.org/Smileys/default/tongue.gif) Note if relay client disconnects from btcd for some reason other peer will take it's place and same shit will happen again
|
|
|
|
|