I had a Windows 7 upgrade (from Home Premium to Ultimate) forced upon me; I was working with a Microsoft Device Emulator and needed to get a .NET Compact Framework application on the emulator to access the network on my Windows 7 host. That required installation of a Virtual PC network driver. Unfortunately, Virtual PC cannot be installed on Windows 7 Home Premium, so I had to upgrade.
To make things worse, an online upgrade is not available where I live. So I had to wait for the upgrade key to be shipped to me.
And when I got the key, things only got worse: I started up Windows Anytime Upgrade and entered the key as requested, and a text kindly informed me that the upgrade would take only 10 minutes. After 1.5 hours, the upgrade was still not done, and there was no network activity, as one could have expected.
I killed the Windows Anytime Upgrade processes and started over again. Same result. Tried to kill as many processes as possible and start over again. Same result. Did a logout and login and started the upgrade once more. Same result. Then decided to restart the machine, but that only made the machine hang during shutdown. After 15 minutes, I pulled the power cord and removed the battery. When I booted the laptop again, the boot manager correctly stated that Windows had not been closed down properly, but I chose to start Windows normally anyway. Windows 7 then started a cycle of 2 or 3 restarts/reconfigurations/updates after which it finally claimed it had upgraded to Windows 7 Ultimate and let me login again.
Needless to say; Windows 7 Ultimate isn’t exactly cheap, so I had expected a smooth upgrade. The experience I had was totally not acceptable!
I’ve recently had a deja-vu while reviewing a proprietary application level protocol; the protocol wasn’t robust with respect to loss of the connection at the transport layer. The reason for this was a design flaw I’ve seen before.
The proprietary protocol relied on a positive acknowledgement transport protocol (like TCP/IP) to ensure that unacknowledged packets got retransmitted. However, lost packets are typically not retransmitted indefinitely. TCP/IP protocol stacks, for example, only try to retransmit unacknowledged packets a limited number of times before aborting the connection.
So, if a connection breaks, how much data can a sender assume that the reciever actual got? Not much, actually. Lack of a positive acknowledgement of a packet could mean that the receiver never got the packet. However, it could also mean that the receiver actually got the packet, but the acknowledgement was somehow lost on its way back to the sender. A broken connection may therefore potentially leave the state of the two peers out-of-synch. When the transport layers become ready to exchange data again, the application layers must somehow be able to continue their protocol without knowing each others precise state.
The best strategy to cope with this problem depends on the problem domain/protocol. Retransmission of the last PDU may be one option, but it will require that the protocol can cope with duplicate PDU’s. Another solution (but often more involved) would be to have the application level protocol let peers probe each others state before continuing normal protocol flow.
Much the same conclusions can be drawn for negative acknowledgement protocols, by the way.
I’ve just released version 0.2.0 of tds2dbg. The new version is now able to insert debug information for public symbols as well as source code references (file and line number) in the dbg files. See http://www.ohloh.net/p/tds2dbg for more information.
Some time ago, I published tds2dbg – a small command line tool that converts Borland debug symbol files (*.tds) to Microsoft debug symbol files (*.dbg). See more on http://tds2dbg.sourceforge.net/
The tool was created while doing consultancy for one of my customers, but the customer was not too keen on maintaining it after I left. We therefore agreed to make it open source.