to reproduce: 1.) run bitcoin, wait for it to connect to net 2.) recycle your dynamic IP (get a new one) 3.) wait for next block 4.) see that new blocks don't show up in your client
expected behaviour: bitcoin should detect that it's disconnected from the network and reconnect.
notes: 1.) the client still shows connection count after the IP change 2.) the connection count will slowly drop to 0 3.) then it will just sit there with 0 connections
Considering how prevalent dynamic IPs are, I would consider this bug to be of a high priority.
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.
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?
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.
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?
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
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".
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.
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.
@molecular Is this still an issue?
I can't easily retest at this point. I'm just going to close the issue. If that's not appropriate, please reopen.
