On Wed, 2007-01-31 at 20:06 +0000, Daniel P. Berrange wrote: > On Wed, Jan 31, 2007 at 07:07:13PM +0000, Mark McLoughlin wrote: > > - If libvirtd is going to be a pure proxy, I don't think the UNIX > > transport is going useful. > > It will be useful for the local Xen case - letting us have a full > read-write connection to Xen even when unprivileged - so we would no > longre have to run virt-manager as root. Isn't that what the existing proxy does? Are we talking about dumping that? (Which reminds me, we can and should auth by uid with the UNIX transport) > > - Also, if it's just a proxy, couldn't this be launched by xinetd? > > That sounds like a reasonable option to allow - at the same time its > nice to have a persistently running daemon to avoid having to re-init > all the one-time TLS stuff for every connection because that can take > a non-negligable time & deplete /dev/random unneccessarily Yep, agreed - you can mitigate the problem by continuing to handle new requests once started and hang around for a time when the last client disconnects ... but bleh. (Total tangent - since xinetd is supposed to be a "resource conserving super-server", I wonder if you could do something where xinetd keeps a cache of TLS params and passes them to servers when they start ... that might be cool) > > - getaddrinfo() is a pretty complicated function, so the code above > > is pretty obtuse without a thorough read of the getaddrinfo() man > > page > > It may be complicated - but this is only because doing the correct thing > for IPv6 is complicated - the traditional getaddr/host related functions > all have a number of flaws which make them unsuitable for modern day > usage. Seriously, if you see that the code I posted *isn't* correct, then I'd like to hear it ... but I don't think you are saying that ... (I'm not being a smartass ... this code is recent and could well be buggy) > > - you really want to end up with *either* a single IPv6 socket or and > > IPv4 socket ... the above code can end up with multiple sockets. > > It can end up with multiple sockets because if a machine has multiple NICs, > it is perfectly possible for a single address to be associated with multiple > NICs. Thus to bind to all interfaces associated with an address, it may be > neccessary to have multiple sockets. Absolutely. But we're not binding to a specific address. Hence, we do only want a single socket. Or to put it another way, if you just want to bind to inaddr_any, then getaddrinfo() just complicates things. For example, on a host with IPv4 and IPv6 address configured, does make_sockets() attempt to bind an ipv6 socket to the port, or an ipv4 one, or both? I suspected it would first try ipv6, then fail at bind() with the ipv4 socket, but I had to write some test code to be sure. There's one caveat to all this - if the code is ported to a system which *requires* both an IPv4 and IPv6 socket because it doesn't allow IPv4 connections to be accepted on an IPv6 socket, then you would need two sockets. Reading: http://httpd.apache.org/docs/trunk/bind.html it suggests that's true on the various BSDs. > > Here's what I prefer to do: > > [snip] > > IMHO, this code isn't simpler /shorter by any significant amount, and it is > far less capable than the code already written above to deal with getaddrinfo. I'd agree that if you intended to allow libvirtd to bind to specific addresses, then you'd need getaddrinfo(). But I do firmly believe that using getaddrinfo() for the inaddr_any case just makes the code obtuse and re-affirms this notion that sockets coding is somehow a black art. If you had to explain the two different versions to someone, I think the getaddrinfo() version would be harder, without being any more correct. > The semantics of the getaddrinfo code are also well documented by Uli if any > reference is needed http://people.redhat.com/drepper/userapi-ipv6.html When I was implementing IPv6 support for Vino, Uli's writeup was my starting point (along with dear old R. Stevens, RIP) ... but I preferred to seriously consider alternatives rather than just copying and pasting it. Anyhow, I never intended to get into such a rant about getaddrinfo() ... it was just a friendly suggestion :) Cheers, Mark.