4 ms·
He 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 compu
by radarsat1 15y ago
He 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.