Thanks for the HUV acronym whatusername, it makes describing things easier. I think you have a pretty good understanding of the system now. I'll reword your de

Thanks for the HUV acronym whatusername, it makes describing things easier. I think you have a pretty good understanding of the system now. I'll reword your description in an effort to clarify, and if this is not the way you understand it please tell me so I can try to make a better explanation. Every bid has 3 possibilities compared to the current HUV: lower, same, higher. LOWER = not a winner simply because it's lower SAME = not a winner because it's a duplicate HIGHER = additional checking required: HIGHER and DUPLICATE = not a winner HIGHER and UNIQUE = winner! That's basically how to determine the status of a new bid. As far as programming tasks are concerned, the value of each new bid must be added to the list of existing bids if it's not already there. Then the status of the new bid must be updated ... and if this changes the status of the HUV, the new HUV must be determined: Determining a new HUV is where sorting becomes necessary, but I think this may be the ONLY place where a sort is required. >>> Behind the scenes - I assume you're logging each bid, details, etc.. You wouldn't have to wait to do this in order to return a result. <<< Yes, logging each bid is important but previously I failed to 'separate' the logging task from the process described above. If the HTTP server can log the cookie value (bidderID) and the post data (bidValue) itself that's all I may need. On the other hand this assumes a new connection to the HTTP server every time a bid is posted -- and if I use Ajax to pass data back and forth without creating these new connections I will also need a separate app to take care of the logging.