Too many NX session reconnections or: Why KDEPrint 'WhatsThis' will be extended, but not complete for 3.4

Bad network connectivity sucks. Sucks big time.

Especially if you had set time aside to work on completing all missing KDEPrint WhatsThis items for the upcoming 3.4 release. Complete string freeze is now very close and I can't do it. At least not the complete thing as intended (bug 97577). (Hey, but some of it you can test already now if you compile CVS....)

Let me tell you a little story. And let's pretend it happened to Yours Truly, even if it was someone else, at a completely different place....

My KDE-HEAD installation is on a remote server. I use the wonderful NX technology to access it and work with a fullscreen KDE 3.4-CVS desktop, as well as doing most job-related develoment work for a certain project.

Starting Monday morning, I experience regular workflow interruptions. Every 2 to 4 minutes my sessions get detached. Network gone! For a very small moment (maybe only a few seconds) no connectivity to the internet.

One year ago, being based on X11, these sessions and the work done within these remote sessions would have been gone forever. But nowadays, the new NX does a beautiful job: it resumes suspended sessions without a hitch, even if it takes a minute. (According to my logs, I had more than 400 disconnections and session restorations over the last 4 days). I did not loose a single bit of data of my work. But of course lots of time I lost, and quite some temper too. The temper has mostly to do with the dump sys and network admins of the place I work from.

But Gian Filippo Pinzari, the lead developer of NX, is my hero now. It is wonderful what you created! The NX session reconnection feature has gone through a real hell of a durability test here. And it has passed it in grand style. Kudos to you! NX saved my day(s)...

Our network admins didn't believe me at first. Supposedly, it was my "exotic software" (of course!) and my "borderline operating system" (what else?) which caused it. "No-one but you is complaining." So I created tcpdumps. I created network traces. I provided ethereal logs. I proofed to them, that for some reason the firewall sent a "FIN" package to initiate the hangup. For two days they resisted. Mails went forth and back. Phones rang. Personal appearances were made in each other's office. (Other users started to shyly complain too -- but these all don't need persistent sessions. They use HTTP. They click on a link, and the website comes to the browser and gets renedered. Very rarely they see a "Proxy not accessible!" error. They try again, and it works. For me it is different: I start an SSH- or NX-session, work for a minute or two, and poooof! -- session disconnected. Login again, re-attach the screen session (NX re-attaches automatically for me... ) ...and do what? Initially, continue to work. Later, try to troubleshoot the problem.

The "admins" of course don't suffer this. Because their "C & C" gaming by-passes the firewall. (So much for having "outsourced" the complete network administration to another company, located in another country.) And they don't incur the disconnections. It took me 2 days of repeated complaints to convince one of them to try and start a large download to his own PC. (I gave him the URL of a special Knoppix ISO image, hehe!). After 4 minutes --- poooof! Download aborted. He starts to investigate. That was last night. They are still investigating now...

I got a modem to connect to the internet. That lets me do at least part of my job: working remotely on a customer's big iron (16 GByte RAM) Solaris "test" machine, installing customized print software. The modem has its limits. And the limits will be hit soon: I approach the stage where I need to actually "print". Since I am not on-site, I intend to re-direct the test jobs (10s of thousands of pages of SAP-generated reports and lists) to my local printers. ((No, I won't print them all on paper. I'll interrupt the jobs after a few pages. And I'll "print to disk" and "print to PDF" to see if all my modifications -- inserting watermarks, changing paper supplies and input trays, etc -- would work for the customer, once the big test environment goes "life" next month.)) -- A modem connection surely isn't the way to test this efficiently. (I need ADSL. Can you hear me??). Time for another complain now. This time to their boss...

So instead of completing... ...a) KDEPrint WhatsThis items, and ...b) a customer job due on Monday, ...I spent most of this week's work time (plus my own evenings) to convince dump, incompetent network admins about a connectivity problem that didnt let me do my work, and troubleshooting it and working around the issue in place of them.

Grrrrh.