At 7:25 AM 9/1/95, Daniel R. Oelke wrote:
I see nothing wrong with the concept of being allocated an initial chunk and having the scan software attempt to ACK it when 50% of it has been searched. A successful ACK would allow the releasing of a new chunk (in response) equal in size to the returned chunk. A failure of the Server to accept the ACK would trigger a retry at set intervals (such as 75% and 100% or 60/70/80/90/100%) until the Server responds. Thus the scanner is always in possession of a Full Sized Chuck to scan (so long as the Server accepts an ACK before the 100% done mark) and temporary failures will not stop the process of a scanner as currently happens.
The only way this can work is if the server is told it is a 50%/75%/etc size ACK, and then latter the server is ACKed for the full 100%.
Why? Because what happens if the client dies immediately after doing the ACK - maybe only 51% of that space has been searched, yet the server has already seen an ACK for it.
You NEVER claim to have searched space until you have actually done so.
IMO - a % ACK is to much complexity and extra work on the server, which is already having trouble keeping up. No. The claim is that the server has no problem keeping up with acks. Besides, if it does, we simply insert a layer of "managers" to buffer the top management from being "bothered" too often.
You are making the "ACK" too complicated. Assuming that you are multi-threaded--- Simply run two "workers" on the same machine. If there are delays in getting keys assigned, the two will soon get out of phase and keep the cpu busy. ---- Richard Wackerbarth rkw@dataplex.net