Tuesday, September 4, 2007

Time-outs

As the more technically advanced readers may be aware, the software programming includes many timers, used for various reasons.
From the simple ones in your BIOS to keep the current clock to high-precision CPU clock counts for real-time applications.
One of the more common uses for timers is the so-called 'time-out'. What does it do, you ask?
Well, imagine that you someday decide to grab a file from your company network. Now suppose that the co-worker's machine, which has the file is turned off. Your trusty OS will ask for the file and then wait for the response. Naturally, you want it to give up at a certain point and tell you that you simply can't have what you want.

Here is what irks me when using Windows and networking together:
- While the explorer window is waiting to refresh it's contents from the network (whether it is a list of computers or a list of files on one of the computers), most of the other functionality of the system is blocked. So, in essence, while the PC sits idly and waits for things to come you have to sit idly and wait as well - since you can't do much else on most occasions. What happened to the so-called 'multi-threading'?
- The timeout length is insanely long for LAN. Here is my reasoning: For quite a while (including windows 95 and onwards) local network have been quite fast. Starting from the popular 10Mb ethernet and 16Mb tokenring, it has so far progressed up to 100Mb and 1000Mb equipment. To calculate this, let's assume that your PC has to send a packet to ask for some file list and receive the response. In a worst-case scenario, the packets are both 'full', taking the maximum 1492 Bytes that most networks support. On a regular 100Mb network, it would take about 0,000228 seconds for the packets to be transferred, add a little something of processing and the timing is still on the range of _MICROSECONDS_. So I ask you... WHY DO I NEED TO WAIT FOR ABOUT 60 SECONDS FOR WINDOWS TO GIVE UP AND DECIDE THAT THERE IS NO REPLY COMING? I think a 10 second timer would be quite sufficient on even the most congested LAN.
- On similar note, the timeout length for Internet communication (specifically DNS resolves) is insanely short. I noticed that if there is no reply from DNS servers the Internet explorer will time out and report an error in UNDER A SECOND for most cases. That may be okay with modern DSL broadband connections, but it was a large problem for the Windows 95 modem-connected people.

At least let us (the advanced users) set our own timeout intervals, no?

No comments: