One of the more frustrating challenges when designing a desktop application that connects to the Internet is figuring out how to deal with connectivity issues caused by firewalls, proxy servers and server outages. Firewalls can be particularly hard to deal with because:
- Almost everyone is using one
- It's hard to tell when your application is being blocked by a firewall
- Most firewalls are too techie for new users to configure
A common problem that we deal with is customers who upgrade to the latest version of FeedDemon, then contact support asking why the new version can't connect to the Internet. In virtually every case, the customer is using a firewall that permitted the previous version to connect, but it silently blocks the new version since the EXE has changed. We've seen this happen with several different software-based firewalls, and each time the solution has been to remove FeedDemon from the firewall's list of permitted applications so that it prompts the user whether to permit FeedDemon to connect the next time it's run.
And as we discovered last week, when your application relies on a server-side API, it has to be able to deal with the server being unavailable without significantly impacting the customer. This was something FeedDemon 2.0 failed to do, and I have to take the blame for this. Because of my poor design, synchronized feeds couldn't be updated while our server was down, and to make matters worse, FeedDemon kept displaying a "synchronization service unavailable" message every time it tried to connect - so not only could you not get new content, but you were also bombarded with error messages you could do nothing about.
Because of this experience, I've been working feverishly on changing how FeedDemon handles the rare situation that our server is down. I don't think I've ever shared a design document before, but since so many customers were (rightfully) unhappy with how FeedDemon dealt with last week's outage, I'd like to share the details of what steps are being taken to improve this situation in the next build of FeedDemon:
Connectivity Improvements in FeedDemon 2.0.0.22 (DRAFT)
In a nutshell, FeedDemon will attempt to detect when a connection failure is due to a problem with our server, and when this happens it will provide a simple way to temporarily disable synchronization so that synchronized feeds are retrieved from their source rather than through NewsGator. This will make updating feeds quite a bit slower (since synched feeds can be updated much faster than non-synched feeds), but it does at least enable reading new content regardless of the state of our server. While synchronization is disabled, FeedDemon will cache items you read so that their read state can be synchronized with NewsGator once synchronization is re-enabled.
This design document - which is still in the draft stage - also covers how FeedDemon will better handle connectivity issues caused by firewalls and proxy servers.
Also Why cant I use Feeddeamon when I dont have Interwab connectivity. Very Annoying.
Posted by: Rob | Monday, April 24, 2006 at 12:56 PM
Have you checked out UPNP and NAT-PMP as autoconfig options?
Posted by: Niall Kennedy | Monday, April 24, 2006 at 02:54 PM
Do connectivity issues plaque every application or plague them? ;)
Posted by: sean | Monday, April 24, 2006 at 04:41 PM
Rob, FeedDemon should work fine without connectivity. There's even a "Work Offline" mode so you can read previously downloaded feeds without any connection.
Niall, I'm a newbie when it comes to UPNP and NAT-PMP. How would they help FeedDemon deal with connectivity issues?
Sean, I meant "plague" :)
Posted by: Nick Bradbury | Monday, April 24, 2006 at 04:54 PM
That's essentially what our connectivity test did on my company's application. However, our app went further and actually downloaded dummy information to verify that every part of the chain was working correctly - that way we could troubleshoot connectivity AND issues like incorrect/corrupted MDAC, Jet, or MSXML installs.
And you better believe connectivity was our main issue - our app did a bunch of other things like invoicing, payments, inventory control, and other business functions. But if it wasn't able to connect to the internet and do its online functions - submit data, receive the daily message, etc. we got a call *immediately* - the connectivity features were less than 5% of our application, but made up more than 95% of our support issues. Connectivity was so much of an issue that I had to write a connectivity-specific troubleshooting guide for our field reps that covered things like configuring software firewalls that needed updating with every new release, hand entering proxy info that couldn't (or wouldn't) be autodetected, and checking whether the customer really had an ISP or just thought so because his system came with a modem (:)), so I feel your pain, believe me.
Posted by: critter42 | Monday, April 24, 2006 at 06:44 PM
Nick,
That's more than I would had asked for to disable the sync and take directly from the source. Great plan. Thanks!
Posted by: Gabe Kangas | Monday, April 24, 2006 at 07:05 PM
Ran into the same problems on our app as well, and we resorted to the "connect test" as well, to try to lead users through the process of testing and telling them to open up their firewalls to let our communication through.
We use TCP/IP so that our software can talk to a database that happens to be local (and eventually we'll have it talking across a LAN). It's a LOT of fun when you have customers who use firewall software which considers even traffic that stays "within the same machine" (ie, localhost to localhost), to be a "risk", and alerts the user that the application is trying to access the Internet.
Not only that, but during a recent test of our app on a computer that had some popular internet security suite, that security software threw up an alert that our applications launches another application which "may put your computer at risk". Of course, there is no risk, but the messages were scary enough that you're naive computer user is going to hit the "Deny access" button and then nothing works.
This stuff is a support nightmare.
Posted by: Mark Sicignano | Monday, April 24, 2006 at 09:41 PM
Nick: Maybe you can change the text "SOAP request" because is too techie.
Posted by: edddy | Monday, April 24, 2006 at 11:40 PM
FYO:(for your eyes only)
I have windows 98, ram 160, pentium ii 400 mhz and i was using feeddemon 1.5.some and when i changed to ver2.0 feeddemon fail after working some 5 o 10 minutes. I unistalled so i dont remember the exact error message but "something like out of resources" was the error message. Could you check it. I really love feeddemon. Please.
I didnt have firewall problems, i am using zonelabs zonealarm and works wonderful.
for the time being I am using someother rssreader but i am unhappy, sad and so on.
Waiting for your response in your new ver 2.0.some, hopefully works with my machine.
A fan. :(
Note: with ver 1.5.some i didnt have problem. never.
Posted by: Peter | Tuesday, April 25, 2006 at 12:46 AM
I have no specific comments to make on the spec draft itself, other than to say I think your approach of providing this to customers (publicly!) for review is a GREAT way to improve you products. This is why I love FeedDemon. Keep it going Nick!
Posted by: Alex Barnett | Tuesday, April 25, 2006 at 01:07 AM
I know how these go with all the hard activity that goes on in the push to the next version, but fwiw I mentioned this issue in the support forums (see the url linked to my username here) during beta testing.
What I would like to know is if there a way I can write these things more clearly so that these issues are noticed and dealt with. I'm afraid that maybe my tone or posting were incorrect and thus ignored because I sounded like a crank, and I don't really want that. FeedDemon is one of the most-used applications I have on my WinXP box, and I value it dearly.
Posted by: moonbiter | Tuesday, April 25, 2006 at 04:09 AM
Yes, I also think you should remove "SOAP request" from your error message text. I'm sure non-techie users will wonder why the heck FeedDemon is requesting soap from Newsgator.com :-)
Posted by: Brian | Tuesday, April 25, 2006 at 05:16 AM
Eddy, Brian: Agreed - few people will know what SOAP is, so I'll change this text.
Peter: We've had two other reports of FeedDemon crashing on Win98, and I was able to track down the cause of the problem. This will be fixed in the next build.
Posted by: Nick Bradbury | Tuesday, April 25, 2006 at 10:16 AM
Moonbiter: Your forum post was clear enough, so in all honesty you didn't need to change your tone or use different wording - we simply dropped the ball and failed to respond.
Posted by: Nick Bradbury | Tuesday, April 25, 2006 at 10:20 AM
The proposed measures sound very intriguing, and far more sophisticated as I have expected! Kudos to you, Nick and Newsgator!
Posted by: Thomas Stache | Tuesday, April 25, 2006 at 10:47 AM
The efforts undertaken by you and the NewsGator Team since "Black Tuesday" continue to leave me impressed. Thanks Nick and I look forward to seeing this valuable update in a future release.
Thank you.
Posted by: The Rooster | Tuesday, April 25, 2006 at 11:19 AM
I think this is an excellent idea, Nick. Especially in those instances where one finds that feeds are syncing "slow" with NGO (or are delayed somewhat substantially). As a technical user,
I knew what to do when I received the error, but having the application constantly remind us it could not sync was quite annoying. I just shut down FD 2.0 until I heard it was back up and running.
Thanks for being as forthright as you have been, though. That's a step to making sure your customers continue to be customers in light of such a serious outage.
Posted by: Jason J. Thomas | Tuesday, April 25, 2006 at 03:41 PM