Or better yet, if the client can't accept a connection, just have it QUIT?
Topic: Non-listening nodes causing huge startup time delays (Read 1387 times)
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?
Or better yet, if the client can't accept a connection, just have it QUIT?
... 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.
Most people who are behind firewalls know they are behind firewalls.
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.
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.
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.
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.
Jump to: