Closed xekoukou closed 9 years ago
From what I can tell, this is pretty much identical to #19, except that instead of giving streams to a thread that is free, it just assigns them in round-robin order? If this is indeed the only difference, then #19 seems strictly better.
Sorry, the name is misleading. I changed the handle_client function to only handle one iteration of the loop. Then the thread switches to a new client. This is the reason that the stddev here is the smallest possible from all the servers.
I thought that this way, we could have the servers work on another client till the previous client was to send the next challenge, thus not waiting the back and forth packet latency, not doing anything.
In my machine, it seams that the latency due to thread context switching was the significant time.
If we had networks with high latency, this would be the ideal solution because the latency of the network would be the significant part.
A good way to check networks with high latency is to put a sleep command inside the client loop.
Then benchmark the servers and see who does best.
Continued in #22.
Very low stddev but comparable mean to rust server.