I talked about acks of acks in a previous message, and I guess is was somewhat vague there. What happened, according to my uninformed view, during the SSL2 challenge was that the server got congested, and had problems with both answering to key allocation requests and ack replies. I guess that the load of the machine was so high that it lost packets in the input queues. Client -----> UDP/Key allocation req ----> Client -----> UDP/Key allocation req ----> Client -----> UDP/Key allocation req ----> Server ---+ | alloc Client <------- UDP/allocation reply ----------------+ | | working... | Client ------- UDP/ack ------------------> ?? One problem was that the client believed that the ACK had arrived at the server if it had sent it off, not counting with the possibility of the ACK being lost on the way. I instead propose that the Server sends a acknowledgement back to the client once it has received an ACK from a client. | working... | Client ------- UDP/ack ------------------> Server -+ | Client <------ UDP/Server-ack ------------ Server -+ And then the client knows the server actually received the ACK and has incorporated it into its table. The client has to handle the case that either the Ack or the Server-ack is lost. I propose it doesn't retransmit immediately, but rather waits until next time it has to ack something, and piggybacks the old ack onto the new one. Client -----> UDP/Key allocation req ----> Client -----> UDP/Key allocation req ----> Client -----> UDP/Key allocation req ----> Server ---+ | alloc Client <------- UDP/allocation reply ----------------+ | | working... | Client ------- UDP/ack1 ------------------> ?? | "oops, oh well, lets try later." | Client -----> UDP/Key allocation req ----> Server ---+ | alloc Client <------- UDP/allocation reply ----------------+ | | working... | Client ------- UDP/ack2/ack1 ------------> Server -+ | Client <------ UDP/Server-ack {1,2} ------ Server -+ | There are countermeasures if either part doesn't get messages for some reason. If the server doesn't see the ACK for a block, it might give that block out to someone else. If the client is unable to retrieve a block from the server, I suggest it just picks a random block and starts working on it. I may very well not be allocated to someone else, and then the client was able to do something good in the meantime even though it didn't get a proper key alloc. /Christian