(Illustration by Gaich Muramatsu)
Hello, I have had some untested/uncommitted code changes for about 4 years now and I feel that the changes become more and more desirable, as the first step in the important and necessary direction. The current implementation of Coda networking heavily uses ipv4 addresses as global and stable (both assumptions are basically not fully correct) indentifiers for the corresponding parties (which is plainly incorrect as "a party" does not correspond to a network interface). This approach looked reasonable very long ago but is no longer tenable. Besides the need to support ipv6 networking I see other very practical reasons to remove the named assumptions, this would allow much more convenient and more robust deployment. I appreciate if you can take time to discuss the changes which I have in mind (and to a certain degree implemented). I outlined some related thoughts earlier in http://www.coda.cs.cmu.edu/maillists/codalist/codalist-2010/9120.html DNS plays a fundamental role for Coda since about 2002 when realms were introduced (which is a hugely important feature). Now I mean to let DNS handle an extra and natural task, to provide and maintain the client's knowledge of the servers' endpoints for the file service (until now DNS was only used to discover the volume location service). ============================================================= I modify the server addressing in the client to consistently use a tuple of (realm,server_number) as a server identifier - this is persistent, global and independent of the network protocol in use. Fortunately this is possible even without introducing any new RPCs, by using the historical artifact - the volume hosting server number is part of a volume id and hence always known to a client. DNS looks like a proper tool to translate (realm,server_number) to a network (address,port). It provides for efficient caching and also for expiration and renewal of the information. The best fitting functionality present in DNS are SRV records even though they are meant for a different scenario. rfc2782 implies that a client is seeking to contact _one_ of the service instances to be located, while a Coda client is meant to contact _multiple_ servers in a realm at the same time. This means that our usage of the SRV records does not and can not follow the rfc2782 literally because the assumptions in the rfc are not applicable. Nevertheless the records are useful and usable for Coda without contradicting the DNS protocol (we are only making an unforeseen actual use of the information got from the SRV record, we already do this since 2002). The priority field in the SRV records remained until now unused. A straightforward and comfortable solution to server location is to let the priority field in an SRV record for a realm to contain the server number (instead of an arbitrary placeholder as until now). This will let the clients easily locate server hosts (and the file service ports) from volume id's, by looking up them in the cached SRV records for a realm. This implies a necessity to put all of a realm's servers into SRV but this hardly looks like a problem (until now it was actually sufficient to put a subset there, but is there anybody who did not put all servers there? if so, then why?). DNS record size limitation might be a potential problem for realms with exceptionally many servers. This is not a practical problem today but may become one. Nevertheless I am pretty sure that this can be addressed when the need arises. One solution would be to reserve an extra "hostname" among the server entries, e.g. with priority 0 and if <smth> with priority 0 encountered in the lookup for _codasrv._udp.rea.lm then the client would have to do an extra lookup for _<smth>._udp.rea.lm and so on until all of the servers of the realm are known which would be indicated by the absence of such a 0-priority record. (<smth> is irrelevant but can be e.g. chosen as codasrv_a, codasrv_b and so on, the exact choice can be left to the realm administrator) To keep the compatibility with a single A record (which is discouraged anyway) such a record could be assumed to correspond to hardwired server number 1. There is otherwise no reason to choose any other/arbitrary server number for the first/single server in a test realm not worth an SRV record - or tell me the reason? An inconvenience related to DNS is its synchronous nature. I intend in the beginning to accept that the client will stall during DNS lookups (which is expected to happen rarely), this can be later replaced by an asynchronous layer. ============================================================= The expected benefits are - possibility to freely move Coda servers both from one ip-number to another (allows among others servers with dynamic ip addresses) and from one f.q.d.n to another (also desirable in practice) - possibility to put multiple Coda-servers (also for multiple realms) behind a single NAT, using different port numbers to distinguish between them - reduced dependency on ipv4 (there will still remain a lot to do, among others on the server side) - occasion to drop the "multiple servers on a single host" hack The order of magnitude of the amount of the corresponding changes in the code can be seen regarding the incomplete code draft: 18 files changed, 508 insertions(+), 401 deletions(-) The numbers will be certainly higher but not too much I hope. I may still have missed some places where a corresponding modification is necessary but impossible or extemely intrusive, then please help me to locate these. I would welcome any participation in the discussion and of course in the code review and coding. Any thoughts/comments? RuneReceived on 2014-07-27 08:26:23