dormando at rydia.net
Fri Feb 1 09:52:10 UTC 2008
Thanks for the clarifications :)
> As a bonus, when the user would give a host name to -l, it will
> resolve to one or several addresses, and memcached will bind to them
> all. This is natural, several addresses were connected to one host
> name in DNS exactly with the purpose that they all will be used for
> this name.
Still following to this point. That's what I figured.
>> IE; if someone wants to bind to a private-network in IPv4 land, they
>> presently use -l, but if you're binding by hostname in IPv6, it
>> makes sense (to me) to continue to allow someone to select a private
> There's no way for memcached to automatically distinct between private
> and public address. You may relay on the address class, but the truth
> is the whole public/private stuff for IPv4 is controlled by your NAT
Right, but my point is the relatively unknown behavior of 'bind by
hostname' by the user. They might think 'bind by local hostname' and
it'll _always_ bind all addresses. I'm seeing room for both, especially
given the portability (fears? issues?).
> The user will still have a full control if he gives IP address (v4 or
> v6) to -l. It would make sense to allow several -l for flexibility
> then. Right now I would have to create a DNS record for a set of
> addresses I want to use, and then use -l set_name to bind to them all
> (that is, if we process all results of getaddrinfo()).
Didn't someone send a patch to allow multiple -l's a while ago? :) Whoops.
> Let me stress this again: first returned address is in no way special.
> Or rather, it is special as it "has the best chances to succeed", but
> this is more relevant to the client side. Actually the return order
> may be configured for a site, and the first returned may be any of
> loopback, site-local, or globally scoped address. More to that, since
> getaddrinfo() can't know how you would use the address, for AI_PASSIVE
> the address with "the best chances to succeed" is likely a global
> externally visible address ;) (if you use host name, that is,
> otherwise it will be INADDR_ANY or IN6ADDR_ANY_INIT). More to that,
> there's the line in Drepper's:
Actually, it appears to be special for completely undefined reasons,
which bugs me for reasons only the esteemed Drepper understands. I get
"has the best chances to succeed" but given the constraints you're
establishing you have to iterate over _all_ of them _anyway_, so what's
the purpose in ordering it? Confusing.
Also, unfortunately, partially broken under different OS's?
> Even if the system can accept IPv4 connection on IPv6 socket, as Linux
> does, you have to bind IPv6 socket to an IPv4-mapped address
> (otherwise you won't be able to connect with IPv4 address). As you
> guess, there's no guarantee that the first returned address is such.
Nor any of them, I guess.
> BTW, that "bug" of OS X 10.5 that was mentioned earlier may not be a
> bug at all: if you iterate over all returned addresses, skipping those
> you can't bind to, you'll eventually succeed (at least because there's
> an IPv4 address down the list). So disabling IPv6 for UDP is an
> incorrect workaround. This would also solve the problem with "older
> glibc returns garbage".
That goes along with my above point of the whole order thing being
silly. I think disabling UDP isn't necessary tho; brian and I were
discussing it a little earlier.
> Brian, if you have any pointers to papers describing the technique you
> propose (use only the first address), sharing them would be very
> appreciated. However, if that's your own invention, then I suggest
> for memcached to stay with the mainstream and be as much secure as the
> rest of the world, at least until this technique will be widely
> recognized and adopted. Forever I guess... ;)
So actually, the most compelling argument is that memcached's code has
exactly two listener sockets, and no method for natively chaining them? :)
In fact, looking at it shows me it's broken it more subtle ways already.
If you set a unix domain socket, tcp and udp are disabled.
tcp is always enabled (unless a unix domain socket is specified)
udp is optional
... and you can only bind one address to each.
So what I propose, right now, in order:
- Whatever minor cleanups are left to make the ipv6 bit work, including
tests that we can throw out.
- Merge it as-is, since you can't multibind without more work anyway.
- Add an option to allow disabling of tcp
- See if we can change the unix domain socket bit to not exclude tcp and
udp (I can see _someone_ wanting to use all three. This whole
discussion's about not restricting it). I'm loathe to change a "default"
tho, so maybe folks have good ideas.
- By "default" the ipv6 code will bind to the first address it finds.
- New option to allow multibinding, for ipv4, ipv6, list of IPs, list of
unix domain sockets, whatever.
Yes? No? I shut up now? :)
More information about the memcached