[Xapian-tickets] [Xapian] #374: IPv6 support

[Xapian]

#374: IPv6 support
----------------------------+-----------------------------------------------
 Reporter:  olly            |       Owner:  olly     
     Type:  defect          |      Status:  new      
 Priority:  normal          |   Milestone:  1.1.7    
Component:  Backend-Remote  |     Version:  SVN trunk
 Severity:  normal          |    Keywords:           
Blockedby:                  |    Platform:  All      
 Blocking:                  |  
----------------------------+-----------------------------------------------

Comment(by james):

 Supporting ipv6 per se isn't terribly difficult; the key thing is to stop
 using `gethostbyname()` and start using `getaddrinfo()`, which
 conveniently returns all the details required to both call `socket()` and
 then either `connect()` or `bind()` (depending on how it's called; there's
 a `AI_PASSIVE` flag that switches between the two modes).

 However there's deeper work that needs doing to do this properly.
 `getaddrinfo()` returns a linked list of `struct addrinfo*`s, and really
 we should bind to all of them (in the server) or try each in turn (in the
 client). The client isn't terribly difficult, but the server will need to
 move from a simply blocking `accept()` call to use something like
 `select()` in order to be able to service things appropriately.

 That will probably be okay by itself (`select()` was in 4.2BSD and is
 supported by Windows, see [http://msdn.microsoft.com/en-
 us/library/ms738639(VS.85).aspx some sample code] and
 [http://msdn.microsoft.com/en-us/library/ms741394(VS.85).aspx the Winsock
 function reference], both on MSDN), and I'd argue we don't need to worry
 about things like `pselect()` under linux, or `kevent()` / `epoll()` and
 friends *right now*. (At some point we may do, given that we're using the
 networking code in the replication system. It might be worth pulling the
 APR in to handle that once we hit there.)

 I've tested the `getaddrinfo()` approach with the simplest possible
 approach, of calling `bind()` only on the first result of `getaddrinfo()`;
 however this isn't a great idea, because people will expect (eg) `xapian-
 tcpsrv --port 9000 --interface localhost testdb` to be accessible over
 ipv4. On my Mac, at least, the first `localhost` address returned is the
 ipv6 `::1`. (We could add logic that prefers ipv4, or a switch or
 something, but that all feels unnatural and moving away from the ideal of
 it just doing the most obvious thing.)

 Incidentally, `getaddrinfo()` has the added benefit of resolving service
 names as well as numeric ports. This suggests that the API of TcpServer
 needs to change to accommodate this.

 I'm quite happy to do this work at some point (say on a branch we can
 point the autobuilders at to get the portability working). We should
 discuss what the "right" behaviour of the server is when a hostname
 resolves to multiple addresses, and when a hostname resolves to multiple
 addresses across different address families. As suggested above, my
 feeling is that binding to all of them across all families, and exiting if
 any fail, is the correct approach. (For clients, trying each in turn until
 one connects is probably fine; there may be some interactions with
 replication clients that may affect this, particularly around
 reconnecting?)

-- 
Ticket URL: <http://trac.xapian.org/ticket/374#comment:1>
Xapian <http://xapian.org/>
Xapian