(Illustration by Gaich Muramatsu)
On Mon, Jul 18, 2005 at 08:07:18AM -0400, Greg Troxel wrote: > iWat <iwatth_at_gmail.com> writes: > > > Hi, I'm a student from Kasetsart Universirt, Thailand. I and my > > friends are going to work on Coda, hacking it to support IPv6. We do > > not sure how long will it takes, and we are very new with Coda, but > > we'll try our best... > > > > There is one question I want to get its answer ... > > - Is there any working project to make Coda runs on IPv6 ? > > I believe that RPC2 now works with v6. Yes it does, actually most of the simple daemons seem to work fine over an IPv6 network. (clog/cpasswd/auth2, updateclnt/updatefetch/updatesrv) I think that even volutil works. However the Coda client and server do not. For one the higher level protocol for volume location queries responds with a single ipv4 address for the server location, but internally they track their peer based on a single IPv4 address. > I believe that Coda encodes IP addresses within the protocol. It may > be appropriate at some point to change the protocol to use an AF > indicator followed by an address. This raises issues of backwards > compatibility. Actually what would be better is to send the unresolved hostname of the server (and a port number) and have the client perform name resolution. That way we also avoid getting those useless 127.0.0.1 or private (internal) network addresses for Coda servers. Tracking clients should probably be done based on the VenusUUID, which is sent when a client binds to a volume with the ViceNewConnectFS call. Any connections that haven't called this should be considered temporary (cmon/volutil) and can be recycled after a timeout, the ones that are bound to a volume have a callback connection which is used to check whether the client is still alive. This might also allow the client to move between different IP addresses (wired->wireless, or 802.11->gprs) with minimal disruption of service. At the moment such a change will trigger a full disconnection. A client can probably get away with a locally unique identifier for servers (pointer to the srvent structure?) Most places where we need a connection we simply follow a set of pointers anyways (replicated volume -> vsg -> mgrp -> srvent -> conn, or volume replica -> srvent -> conn) I think there are only one or two places where we really need to look for the server by ip-address, one is in the code that handles incoming callback connections, but those should really be identified on something like the VenusUUID. > > I don't want the duplication of works, or if there is, so we can share > > information to achive this project ... > > Jan will speak up I'm sure. Nothing committed yet. I had an email from Rod Van Meter the other day who did the initial IPv6 code for RPC2 who wanted to know if there is anything in this area that could possibly be an interesting project for a couple of students. Haven't heard anything back, but even so some duplication might be useful especially since there is nothing at the moment and there might be a lot of interesting little snags that different people solve in different ways. JanReceived on 2005-07-18 15:13:14