From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1EPuAe-0007EZ-2m for qemu-devel@nongnu.org; Wed, 12 Oct 2005 23:54:20 -0400 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1EPuAc-0007EK-D2 for qemu-devel@nongnu.org; Wed, 12 Oct 2005 23:54:19 -0400 Received: from [199.232.76.173] (helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1EPuAc-0007EH-A5 for qemu-devel@nongnu.org; Wed, 12 Oct 2005 23:54:18 -0400 Received: from [69.17.117.26] (helo=mail24.sea5.speakeasy.net) by monty-python.gnu.org with esmtp (TLS-1.0:DHE_RSA_3DES_EDE_CBC_SHA:24) (Exim 4.34) id 1EPuAc-0004XQ-Db for qemu-devel@nongnu.org; Wed, 12 Oct 2005 23:54:18 -0400 Received: from dsl081-088-222.lax1.dsl.speakeasy.net (HELO [192.168.111.2]) (jhoger@[64.81.88.222]) (envelope-sender ) by mail24.sea5.speakeasy.net (qmail-ldap-1.03) with SMTP for ; 13 Oct 2005 03:54:11 -0000 Subject: Re: [Qemu-devel] [patch] robust user-mode networking From: "John R. Hogerhuis" In-Reply-To: <434DC79D.5040100@stanfordalumni.org> References: <434DC79D.5040100@stanfordalumni.org> Content-Type: text/plain Date: Wed, 12 Oct 2005 20:54:22 -0700 Message-Id: <1129175662.13382.111.camel@aragorn> Mime-Version: 1.0 Content-Transfer-Encoding: 7bit Reply-To: jhoger@pobox.com, qemu-devel@nongnu.org List-Id: qemu-devel.nongnu.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: qemu-devel@nongnu.org I don't know a lot about Slirp details other than what I generally know about proxy server and NAT router implementation (I know a lot about that). But perhaps I can raise some questions for you. On Wed, 2005-10-12 at 22:34 -0400, John Coiner wrote: > The alternative would have been to debug the slirp stack, and understand > how it works and why Windows leaves it in a frozen state, when disabling > and reenabling the NIC. I have no idea what 'frozen state' means in this context. Do you? I guess not, since I suppose as soon as you really knew you would be in a position to kill the fly with a fly swatter rather than running over it with your car :-). Not a criticism just a nudge... this sounds like a tiny bug somewhere that deserves squashing rather than hiding. Unless you can think of other uses for a Slirp stack resettable independent of qemu itself, it seems like overkill. However, such a feature might well have some general utility though, so it seems like it would be a waste not to include it. Maybe you could explain why you find a need to disable/re-enable the network card... What happens in the normal case to the software stack when a network card is reset? Would all TCP connections that hadn't timed out yet time out? That is, would the set of allocated sockets be freed back to the pool? Slirp maintains context about every connection passing through it since it is a proxy server. So if you reset it all those connections would be dropped. So even if the socket was left open on the guest, it would definitely be dropped in slirp. Maybe that's what is supposed to happen. Maybe it doesn't matter either way, since this is the kind of thing firewalls do all the time. Applications are supposed to be able to deal with it. -- John.