dynamic IP change -> silent network disconnect about bitcoin HOT 13 CLOSED

Considering how prevalent dynamic IPs are, I would consider this bug to be of a high priority.

from bitcoin.

The client should never end up with 0 connections, as it always tries to keep MAX_OUTBOUT_CONNECTIONS open (8). In my testing, a dynamic ip change will keep connections open. However, connections take 90 minutes to timeout, so there is a time where your client thinks its connected, but is actually not. That should be fixed, but I have never seen a complete silent disconnect. I might be wrong but please add a test case which always causes this if you do see this often.

from bitcoin.

Is 90 minutes really a reasonable period to wait before timing out a connection? That's an hour and a half... I suppose there is no kind of heartbeat packet to help speed the timeout?

from bitcoin.

TheBlueMatt: what you're saying does not hold true for me... I started a 0.3.20.1 beta node on testnet about 3 days ago. It got stuck at 10870 blocks (that block was mined 2 days ago). It says "0 connections" and does not reconnect.
While this is not "silent" (assuming after 90 minutes it shows 0 connections), it's a complete disconnect (persisting for probably 2 days now) and should not happen, as most will agree.

from bitcoin.

jeffWelling: according to ArtForz, there is a heartbeat packet sent every 30 minutes (provided no other txes/blocks/etc have been send in the last 30 minutes). I guess the timeout could reasonably be decreased as content sent by TCP should be reliable.

molecular: Odd, I guess this needs more long-term testing (I only tested by artificially setting the timeout to a low value). Ill try to do this when I get the chance. Can you grep some debug.log stuff out when this happens?

from bitcoin.

testing the whole thing once more:
1.) start 0.3.20.1 beta -testnet (wait to sync blockchain to block 10882)
2.) mine a block (block now 10883)
3.) switch IP
4.) observe a new block arriving (block 10884): so in fact at least one connection survived the IP switch! I did not expect this.
5.) mine 3 more blocks
6.) notice something very strange: it says "2/offline? - generated - warning: this block was not received by any other nodes and will probably not be accepted!" on newly (after IP switch) mined blocks, "2 connections". I still received other blocks after IP switch, though.

here's a screenshot to illustrate the situation: http://i.imgur.com/xlzY1.jpg

from bitcoin.

to complete above test report:

7.) went to eat, came back, found this: "0 connections, 10893 blocks", the block generation(s) shown as "2/offline?" in 6.), now show as "7 confirmations". I don't seem to receive new blocks any more, stuck at 10893, blockexplorer: 10898
8.) concluding that the node is disconnected for real, the IP switch was more than 3 hours ago.

here's a slightly grepped version of the debug.log (I marked the point where the IP changed, line 123): http://pastebin.com/rmSEcAXA

note: it seems from the debug.log I didn't wait for the blockchain to sync before I switched the IP address. This, I think, explains the "2/offline?"-stuff.

Summary: this is now an example of a "non-silent complete disconnect".

from bitcoin.

Since this seems to affect both incoming and outgoing connections and occurs on an event that at least some users will encounter with some frequency (and can't easily avoid), I would say this should be considered a fairly high priority issue. It's obvious why this affects inbound connections (if you didn't think about this issue and design around it, that would happen by itself). It's quite mysterious that it affects outbound connections.

A lot of programs have issues on dynamic IP changes.

from bitcoin.

Is there any way at all to detect network connect/disconnects, even in a platform-depending manner? Re-executing the "detect local ip" logic is no problem at all, but we can't do it continuously.

from bitcoin.

@sipa Why not peridoically re-check (local) IPs or query via UPnP?

from bitcoin.

There was discussion on IRC about this today, IIRC #3088 is a step toward improvement here

from bitcoin.

@molecular Is this still an issue?

from bitcoin.

I can't easily retest at this point. I'm just going to close the issue. If that's not appropriate, please reopen.

from bitcoin.