Bitcoin v0.4.0 (Linux) stale connections handling

[modrobert]

I use an ISP which forces a new IP address via DHCP every 24 hours, and they are pretty big, roughly 2 million users in Thailand total.

When the IP address changes the Bitcoin client slowly drops all stale connections above 8 connections. This means I have to restart the Bitcoin client to make it go above 8 connections once every day.

If I skip restarting the client, the effect is probably worse for the network as a whole than me personally, since having lots of connections active benefits the Bitcoin transaction system.

Is there any way to fix this in the Bitcoin client to handle stale connections after IP address change better?

EDIT:

Forgot to mention I use Bitcoin v0.4.0 for Linux.

[1715341513]

1715341513

[tcatm]

IIRC the problem is because your router is not closing those TCP connections correctly so as far as bitcoin is concerned those connections are still open.

[Herbert]

I had linux client 0.4.0 running overnight for several times and never noticed a decrease in connections (Also getting new IP every 24hours). So indeed this looks more like a problem on your side, not a general issue.

[modrobert]

IIRC the problem is because your router is not closing those TCP connections correctly so as far as bitcoin is concerned those connections are still open.

If that was the case, the Bitcoin client wouldn't go down from say 100+ connections to 8 open connections (as shown in the GUI status row) after IP address change, right?

I had linux client 0.4.0 running overnight for several times and never noticed a decrease in connections (Also getting new IP every 24hours). So indeed this looks more like a problem on your side, not a general issue.

Interesting, how many connections did the Bitcoin client report to have open when you tested this?

Might be worth noting that other software I use for mining (poclbm.py), irc, usenet and bittorrent does handle the IP address change without a problem.

I could easily write a script which kills and restart the Bitcoin client whenever the IP address changes, but that would be more of a workaround than actual fix.

UPDATE:

I've been checking the source code here:

https://github.com/bitcoin/bitcoin/blob/master/src/net.cpp#L405

The functions ThreadGetMyExternalIP() and GetMyExternalIP() specifically. I guess the problem is related to how the IP address is cached when received from either IRC (Server IP: 92.243.23.21), or when the backup services dyndns.org and showmyip.com are used (Yes, to my surprise the Bitcoin client actually rely on these services hardcoded).

It seems these functions aren't called properly when my router get new IP address via DHCP, so no incoming connections can reach the host because the old IP address is used, only the 8 connections which are outgoing still reconnects ok after timing out.

[Herbert]

I stand corrected.
Just did the following: Start up client, wait until ~150 connections are there, disconnect & reconnect router.
=> Client starts loosing connections and stays down at 8.

Sorry for being ignorant 

[modrobert]

Any Bitcoin developers care to fix this problem?

[Gavin Andresen]

Any Bitcoin developers care to fix this problem?

Let me think... a problem that affects a small number of people... means you end up with 8 connections instead of more than 8... and has an easy, obvious workaround... and if fixed will be difficult to test thoroughly...

Not high on my priority list.

Things that ARE high on my priority list:

+ Getting the 0.5 release out the door
+ Improving initial startup and block download times
+ Solutions for wallet security and backup

[modrobert]

Ok, I'm testing the socks4 proxy function for now as a workaround.

Actually having more than 8 connections isn't important to me personally at all, I was under the impression it was for Bitcoin, can't find the post where I read that though.

[Matt Corallo]

This has been an issue for a long, long time.  There are several bugs on the subject, but no one has ever bothered to fix it, because its really just not that big of a deal...anyway, patches welcome.