On Mittwoch, 2. Dezember 2009, Erik Faye-Lund wrote: > On Fri, Nov 27, 2009 at 8:59 PM, Johannes Sixt <j6t@xxxxxxxx> wrote: > > "relatively small chance of stuff blowing up"? The docs of > > TerminateThread: "... the kernel32 state for the thread's process could > > be inconsistent." That's scary if we are talking about a process that > > should run for days or weeks without interruption. > > I think there's a misunderstanding here. I thought your suggestion was > to simply call die(), which would take down the main process. After > reading this explanation, I think you're talking about giving an error > and rejecting the connection instead. Which makes more sense than to > risk crashing the main-process, indeed. Just rejecting a connection is certainly the simplest do to keep the daemon process alive. But the server can be DoS-ed from a single source IP. Currently git-daemon can only be DDoS-ed because there is a maximum number of connections, which are not closed if all of them originate from different IPs. > > Case 2 could be achieved by using setsockopt() with SO_RCVTIMEO and > > SO_SNDTIMEO and a tiny timeout. But notice that we would set a timeout in > > one thread while another thread is waiting in ReadFile() or WriteFile(). > > Would that work? > > I think it should work fine, but I won't give you a guarantee ;) > Perhaps we should have a configurable global max timeout, and just set > that on all sockets? Or does this open for DDOS attacks? I'm sure that there is a global timeout already, but it is in the order of minutes, which is too long. Here I mean it to be set to zero or one milli-second so that the connection closes right away - as if the process on the server side had been killed. Hm - perhaps it is possible to really *close* the socket while some other thread waits in ReadFile() or WriteFile()? -- Hannes -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html