Code review comment for lp:~martin-v/zodb/ipv6

Revision history for this message
Martin v. Löwis (martin-v) wrote :

>> The IPv6 server code is entirely different: typically, you either
>> bind to all addresses (v4 and v6) of a system (preferably using
>> dual-stack sockets using a wildcard address), or you bind to a (list
>> of) specifically configured addresses; no DNS involved.
>
> I wonder why the asymmetry. Or, at least, why it wouldn't at least
> make sense to at least listen for both v4 and v6 for the same host name.

It always was asymmetric: you can use a wildcard address on the server,
but not on the client, as a special feature of the socket API.

Some servers support binding to multiple explicit interfaces (e.g.
Apache Listen), but I'm not aware of a precedent that supports
DNS in that part of the configuration, and supports DNS returning
multiple addresses (i.e. expanding them to multiple Listen statements).

> I have wanted to be able to listen on both a TCP socket and a
> unix-domain socket. There's nothing hard about this for ZEO per se,
> but figuring how to spell this in ZConfig schema has been just enough
> of a pain to make it not happen. :)

Ok. So do you want me to change the patch to bind to multiple addresses?

I think StorageServer would need to change, to support multiple
addresses, and also multiple Dispatcher objects.

> I don't mind trying multiple paths (addresses) to do the low-level
> connections, but I'm worried about making multiple connections to the
> same server.

I could try to find out how to prevent that: it should be possible
to keep track what DNS names each connection originated from, and then
close any redundant connections that get connected (assuming zrpc
can deal with connections on which no data gets transmitted).

> I'm good with merging the branch. Do you want to do this (using some
> LP tool)? Or do you want me to?

I would rather see you merge the patch. However, if you want me to
make some modifications first, we can also wait (I won't be able to
work on this really for the next two weeks).

« Back to merge proposal