Re: [Qemu-devel] [patch] robust user-mode networking

["John R. Hogerhuis" <jhoger@pobox.com>]

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.