Server congestion
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
I talked about acks of acks in a previous message, and I guess is was somewhat vague there.
... and maybe based on a false premis ?
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.
Correct.
I guess that the load of the machine was so high that it lost packets in the input queues.
NO. The load was very *LOW*. The problem was that the single threaded server was spending most of its time talking to clients which failed to complete their interactions, and timed out. The earlier client "ACK" code didn't hang around long enough, and gave up. Later code kept trying ....
Client -----> UDP/Key allocation req ---->
Nope -- basic fault here !! TCP not UDP !!
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.
Not the case. It uses a reliable bytestream, and the client does not consider a keyspace ACKed until it get back the "OK" response from the server. This makes it "at least once", but that isn't a problem.
I instead propose that the Server sends a acknowledgement back to the client once it has received an ACK from a client.
It does, in the reliable bytestream ...
The client has to handle the case that either the Ack or the Server-ack is lost.
As above -- "at least once" -- it just retries.
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.
brclient waits a bit and tries again, before asking for the next.
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.
Nah.
| > I talked about acks of acks in a previous message, and I guess is was | > somewhat vague there. | | ... and maybe based on a false premis ? | | > 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. | | Correct. | | > I guess that the load of the machine was so high that it lost packets in the | > input queues. | | NO. | | The load was very *LOW*. | The problem was that the single threaded server was spending most of its ti me | talking to clients which failed to complete their interactions, and timed o ut. | The earlier client "ACK" code didn't hang around long enough, and gave up. | Later code kept trying .... | | > Client -----> UDP/Key allocation req ----> | | Nope -- basic fault here !! TCP not UDP !! Ok, I'll be quiet now. It's funny when you think you know what is happening based on an uninformed view, and simply shuts out all the other pieces of info that gets to you. By the way, thanks a lot Piete for the effort you put in! You did excellent, and it was real fun! 32 hours with serious performance problems is simply amazing. /Christian
participants (2)
-
Christian Wettergren -
Piete Brooks