Hacker News Reader

Comment by AndyKelley | Hacker News Reader

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."

View on HN

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.

> 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.)

Definitely, asserting non-blocking flags for the socket options is also a good idea.

Are 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.

I 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.

ah, there's the missing piece of information. Now I got it, thanks.

It's just a hypothesis. Obviously I don't have enough information to know for sure.

Reply on news.ycombinator.com