Bitcoin Forum
December 07, 2016, 02:44:29 PM *
News: Latest stable version of Bitcoin Core: 0.13.1  [Torrent].
 
   Home   Help Search Donate Login Register  
Pages: [1]
  Print  
Author Topic: Non-listening nodes causing huge startup time delays  (Read 1122 times)
Mike Hearn
Legendary
*
expert
Offline Offline

Activity: 1526


View Profile
June 01, 2011, 03:34:31 PM
 #1

I noticed a few times now that Bitcoin can take several minutes to establish a network connection. The reason is that lots of non-listening nodes are sitting in IRC, and ThreadOpenConnection tries them sequentially. The connection attempt can take a long time to give up, so if you get several non-listening nodes in a row, it takes forever to connect.

I think a simple solution would be to change the nick format used by nodes that aren't listening, or use DNS discovery by default.
1481121869
Hero Member
*
Offline Offline

Posts: 1481121869

View Profile Personal Message (Offline)

Ignore
1481121869
Reply with quote  #2

1481121869
Report to moderator
1481121869
Hero Member
*
Offline Offline

Posts: 1481121869

View Profile Personal Message (Offline)

Ignore
1481121869
Reply with quote  #2

1481121869
Report to moderator
1481121869
Hero Member
*
Offline Offline

Posts: 1481121869

View Profile Personal Message (Offline)

Ignore
1481121869
Reply with quote  #2

1481121869
Report to moderator
Advertised sites are not endorsed by the Bitcoin Forum. They may be unsafe, untrustworthy, or illegal in your jurisdiction. Advertise here.
1481121869
Hero Member
*
Offline Offline

Posts: 1481121869

View Profile Personal Message (Offline)

Ignore
1481121869
Reply with quote  #2

1481121869
Report to moderator
gmaxwell
Moderator
Legendary
*
qt
Offline Offline

Activity: 2030



View Profile
June 02, 2011, 03:58:31 AM
 #2

see also:
http://forum.bitcoin.org/index.php?topic=11126.msg158368#msg158368
and
http://forum.bitcoin.org/index.php?topic=8894.msg158376#msg158376

There was some discussion in #bitcoin-dev about signaling non-listening nodes too but the problem is that nodes can't currently tell if inbound connections work. Some logic can be added to request peers to try connecting before deciding that you're listening and announcing, but it's more than a few LOC...

The general idea was that nodes would wait some amount of time (we only really care about high uptime nodes listening) then request some of their peers to connect to them. If it works then they advertise themselves as listening. This doesn't just matter for IRC but also for the peer requests over the p2p protocol.

It didn't sound like anyone had committed to writing that yet.

I think it sounds like all of these things (incl. DNS seed and the other stuff in the linked thread) need to happen eventually, but fixing the connection timeouts plus anything else is enough to meet the urgent need.

realnowhereman
Hero Member
*****
Offline Offline

Activity: 504



View Profile
June 04, 2011, 02:24:29 PM
 #3

... Or we could just have a checkbox that said "allow incoming connections", and not connect to IRC when it's not ticked?

Most people who are behind firewalls know they are behind firewalls.

1AAZ4xBHbiCr96nsZJ8jtPkSzsg1CqhwDa
Luke-Jr
Legendary
*
expert
Offline Offline

Activity: 2086



View Profile
June 04, 2011, 03:06:51 PM
 #4

The IRC code seems to already detect if it's firewalled and change its nick if so... Could just skip those nicks, if it doesn't already.
Or better yet, if the client can't accept a connection, just have it QUIT? Tongue

Pages: [1]
  Print  
 
Jump to:  

Sponsored by , a Bitcoin-accepting VPN.
Powered by MySQL Powered by PHP Powered by SMF 1.1.19 | SMF © 2006-2009, Simple Machines Valid XHTML 1.0! Valid CSS!