Re: How (and why) to use the Relay Network

[Matt Corallo]

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 

Fixed server memory usage, bumped the buffer size, should work now?

Nope:

...still getting flooded with large tx's all the same size too 

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]

...

Strange, the us-west node works for me?

Fixed by commenting these out:

Code:

+               //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]

Fixed by commenting these out:

Code:

+               //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]

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]

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

[bicer]

Is constant "(out-of-band)" normal?

Code:

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]

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

[kano]

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]

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]

You wouldn't happen to have an ETA on this?

Yes, it should be resolved by now.

[p3yot33at3r]

I'm still getting disconnects I'm afraid, but not constant as before:

Code:

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]

You wouldn't happen to have an ETA on this?

Yes, it should be resolved by now.

Yep all the numbers looking OK again
Last 9999 messages: Sent: 5752 Received: 4224

[Matt Corallo]

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]

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]

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]

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]

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:

Code:

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  

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:

Code:

rpcthreads=10

...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  

I'll keep an eye on it, but hopefully this info will prove useful to other merge miners.

[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

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  
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]

Code:

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  

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:

Code:

rpcthreads=10

...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  

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]

Super  
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
Note if relay client disconnects from btcd for some reason other peer will take it's place and same shit will happen again