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. _______________________________________________ Qemu-devel mailing list Qemu-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/qemu-devel
