Created attachment 59186 [details]
small section of dbus-monitor output during connection failures

Version:           unspecified (using KDE 4.6.1) 
OS:                Linux

If the api.opendesktop.org is unreachable due to any kind of networking problem (ie company blacklisting of the remote server, temporary failure at the host) the "Add New " (Colors, Widgets, Themes, Decorations) functionalities in kcm_colors, kcm_kwindecoration, kcm_style, kcm_ksplashthememgr don't gracefully stop trying to get connections after a reasonable time and warn the user that the remote resource is unreachable but rather floods the host network with thousands of connection attempts.  Although the absence of api.opendesktop.org is not really normally expected, the kde theme update system should gracefully stop trying to get themes/widgets/colors, etc if it is missing.

Reproducible: Always

Steps to Reproduce:
Run KDE4 on a network that blacklists opendesktop.org or otherwise fails to pass a good IP to the update system. Go in System Settings -> Application Appearance (or Workspace Appearance or Login Screen) or attempt to use the Get New Widgets button from Add Widgets from the desktop menu.  Use the "Add New ..." button from any of these.

Actual Results:  
Network traffic will take off as each connection fails. This is visible by monitoring dbus-monitor and running the network monitor plasma widget.  User must logout of KDE to stop (or likely it would work to stop the systemsettings process manually).  The user is never informed that something is wrong, without a network load widget they would likely not notice other than slow web browsing.

Expected Results:  
It should have attempted for some reasonable time (20" or 30") to contact api.opendesktop.org, counted the failures and given up and used the built-in KDE notification system to tell the user that the themes/widgets/decorations are not available due to a network error.  The unavailability of opendesktop.org is not usually expected for a typical user but if it does happen KDE should be able to handle it instead of flooding the local network. As far as I can tell, it would continue indefinitely to try to connect to opendesktop.  

This is a bad because the updater will try many thousands of connection attempts and doesn't seem to stop. I didn't want to flood my network at work so I've never let it just run its course.  I can't test this at home because api.opendesktop.org is not blocked there.  I could possibly hack up pointing api.opendesktop.org to localhost at home and retry this.  In my last test, the updater was allowed to run just a minute or so and failed 2800 connections.
Attached is a small chunk of the dbus-monitor output I got.
https://host.domain/messages/dns.html  is an internal dns blockage warning in our network that I've obscured.