3 ms·
I'm not completely satisfied by the explanation. I still have that uneasy feeling that you get when you solve a bug, but an unsolved mystery remains. "Also, I s
by AndyKelley 15y ago
I'm not completely satisfied by the explanation. I still have that uneasy feeling that you get when you solve a bug, but an unsolved mystery remains. "Also, I still don't know why not all consoles connected to that PC froze."
- radarsat1 15y agoHe didn't mention how the logging was done but if it was over a TCP connection then the send() call probably blocked until it timed out since the sleeping computer didn't close the socket nicely, then it had to re-establish the connection. Although reliability is nice, if I were writing a remote logger for a something like a game, I think I'd use UDP.
- AndyKelley 15y agoAre you trying to explain how it's possible for some of the consoles to freeze but others not while talking to the same sleeping computer? If so, I did not understand your explanation.
- alexgartrell 15y agoI believe socket writes don't block until you've filled the internal socket buffer, so it's likely that the unaffected machines simply hadn't done this yet.
- AndyKelley 15y agoah, there's the missing piece of information. Now I got it, thanks.
- radarsat1 15y agoIt's just a hypothesis. Obviously I don't have enough information to know for sure.
- Nick_C 15y ago> although reliability is nice ... UDP Would you not use send() with MSG_DONTWAIT? You get the reliability of TCP and you get feedback if there is any potential blocking. (But I certainly am not a socket guru.)
- radarsat1 15y agoDefinitely, asserting non-blocking flags for the socket options is also a good idea.