|
|
Created:
15 years, 7 months ago by cw Modified:
15 years, 6 months ago Reviewers:
CC:
golang-dev, rsc, r, dho, nictuku Visibility:
Public. |
Descriptionnet: Initial (rough) /etc/hosts parsing + lookup support.
Patch Set 1 #Patch Set 2 : code review 181063: net: Initial (rough) /etc/hosts parsing + lookup support. #Patch Set 3 : code review 181063: net: Initial (rough) /etc/hosts parsing + lookup support. #Patch Set 4 : code review 181063: net: Initial (rough) /etc/hosts parsing + lookup support. #Patch Set 5 : code review 181063: net: Initial (rough) /etc/hosts parsing + lookup support. #
Total comments: 3
MessagesTotal messages: 14
Hello rsc, r (cc: golang-dev@googlegroups.com), I'd like you to review the following change.
Sign in to reply to this message.
Hello rsc, r (cc: golang-dev@googlegroups.com), I'd like you to review the following change.
Sign in to reply to this message.
+krasin On Dec 25, 2009 1:04 PM, <cw@f00f.org> wrote: Hello rsc, r (cc: golang-dev@googlegroups.com), I'd like you to review the following change. http://codereview.appspot.com/181063
Sign in to reply to this message.
On 2009/12/26 14:25:55, rsc wrote: > +krasin > > On Dec 25, 2009 1:04 PM, <mailto:cw@f00f.org> wrote: > > Hello rsc, r (cc: mailto:golang-dev@googlegroups.com), I'd like you to review the > following change. > > http://codereview.appspot.com/181063 Only thing about this patch is that it ignores any nsswitch.conf (or similar configuration) that determines what is looked at first. For example, FreeBSD will allow you to specify (in order) whether you want to look in nis, files (/etc/hosts), or dns. I suspect other systems have similar things as well. In this case, it may not be true that we want to look in /etc/hosts first. Food for thought.
Sign in to reply to this message.
On Sat, Dec 26, 2009 at 04:50:42PM +0000, devon.odell@gmail.com wrote: > Only thing about this patch is that it ignores any nsswitch.conf (or > similar configuration) that determines what is looked at first. I'll add support for that in so far as I easily can. One issue here is that there can be arbitrary tokens on the RHS that refer to nss libraries which libc will dynamically load. For now we probably have to ignore tokens we don't grok, long term perhaps we'll end up with some dlopen + ffi uglies --- which will likely require splitting the 'top level' resolver functions up for each platform/OS (I already considered doing that because uname isn't uniform across the currently supported platforms).
Sign in to reply to this message.
[Sorry this is a bit long-winded and probably full of errors] Looking at this a bit more, I don't think adding even basic nss support will be very useful. If think if we check /etc/hosts then dns it will work 'as expected' for most people, more so that not checking /etc/hosts at all. We should document this. Further more: * /etc/nsswitch.conf is fairly tightly coupled to libc on a system; Go really shouldn't be deeply bound to that (beyond what is necessary) * for anything other and `files' and `dns' we'll need some ffi interface and dynamic library loading support; at present this isn't possible * even with some ffi support, the interfaces are quite different to the Go interfaces, rather they are very much aligned to libc which would tend to make the glue fairly ugly * if we do get some ffi interface glue, it would be used for /etc/hosts and dns lookups directly; however this would be certain Go APIs are really abstracted out libc interfaces and their behavior be beholden to upstream changes there * FreeBSD & Linux have /etc/nsswitch.conf, Windows and Darwin do not * what about nscd? should we at some point interface to nscd when there is a suitable socket to talk to? how far do we go, just queries or do we go as far as getting an fd over the socket to mmap a RO version of the cache with (glibc) can do this * i think Darwin probably has some nscd or resolver interface we could talk to should we decide to, what about Windows? * it seems likely (i'll do it if nobody else does) that we'll hoist the DNS code out of net/ into it's own package(s) and potentially flesh out some sort of resolver interface; i already have code (real code, not toys) that would like to get TXT records * most people (waving hands about furiously) probably use defaults (or compat) settings for hosts so checking hosts then dns would work in those cases, for others we can leave this as an open issue to revisit once we have more feedback and more of a chance to think about how this should work
Sign in to reply to this message.
A few comments. By the way, as I mentioned in the issue #313, I'm writing a patch for this that could also be considered for inclusion. It's not quite ready yet, but it looks more complete than yours IMO. http://codereview.appspot.com/181063/diff/8/1007 File src/pkg/net/dnsclient.go (right): http://codereview.appspot.com/181063/diff/8/1007#newcode187 src/pkg/net/dnsclient.go:187: // read and parse /etc/hosts into a map Properly capitalize and add ending periods to your comments. They must be proper English sentences. // Read and parse /etc/hosts into a map. Same for other cases below. http://codereview.appspot.com/181063/diff/8/1007#newcode192 src/pkg/net/dnsclient.go:192: hostdata, err := ioutil.ReadFile("/etc/hosts") rsc mentioned in a private email that he wanted as less dependencies as possible in the 'net' package. I don't know if io/ioutil could be a problem. http://codereview.appspot.com/181063/diff/8/1007#newcode265 src/pkg/net/dnsclient.go:265: once.Do(loadEtcHosts) Then if /etc/hosts is changed, the program would never get this. You should consider using a cache and update this value from time to time.
Sign in to reply to this message.
On Sun, Dec 27, 2009 at 04:13:08AM +0000, yves.junqueira@gmail.com wrote: > Properly capitalize and add ending periods to your comments. They > must be proper English sentences. ack > rsc mentioned in a private email that he wanted as less dependencies as > possible in the 'net' package. I don't know if io/ioutil could be a > problem. it could be changed easily enough, io is used right now, it's not clear ioutil is much 'worse' > Then if /etc/hosts is changed, the program would never get this. You > should consider using a cache and update this value from time to > time. yes, i have support for that as well as for /etc/resolv.conf changing over time i got a bit side-tracked trying to do something sensible with /etc/nsswitch.conf before deciding that should wait for now
Sign in to reply to this message.
2009/12/26 <cw@f00f.org>: > [Sorry this is a bit long-winded and probably full of errors] > > Looking at this a bit more, I don't think adding even basic nss support > will be very useful. No problem. I think that comment was more meant towards long-term thoughts for how it should be addressed. > If think if we check /etc/hosts then dns it will work 'as expected' for > most people, more so that not checking /etc/hosts at all. We should > document this. Very much agreed. At least currently, the likelihood of someone using Go along with a system that uses nsswitch is very low at this point. > Further more: > > * /etc/nsswitch.conf is fairly tightly coupled to libc on a system; Go > really shouldn't be deeply bound to that (beyond what is necessary) > > * for anything other and `files' and `dns' we'll need some ffi interface > and dynamic library loading support; at present this isn't possible Agreed. > * even with some ffi support, the interfaces are quite different to the > Go interfaces, rather they are very much aligned to libc which would > tend to make the glue fairly ugly > > * if we do get some ffi interface glue, it would be used for /etc/hosts > and dns lookups directly; however this would be certain Go APIs are > really abstracted out libc interfaces and their behavior be beholden to > upstream changes there The way that Go seems to do these things at this point is to create auto-generated wrappers (see also pkg/syscall, for example) around the `tightly coupled' areas. It's unfortunate that nsswitch is this short-sighted. However, for systems such as FreeBSD that are packaged as a coupled kernel and environment, there isn't really a great way around this. I wonder how difficult it would be to add cgo wrappers for these things. > * FreeBSD & Linux have /etc/nsswitch.conf, Windows and Darwin do not > > * what about nscd? should we at some point interface to nscd when > there is a suitable socket to talk to? how far do we go, just queries > or do we go as far as getting an fd over the socket to mmap a RO version > of the cache with (glibc) can do this `At some point' we do whatever allows us to achieve the best performance on $GOOS that we can. > * i think Darwin probably has some nscd or resolver interface we could > talk to should we decide to, what about Windows? I think Windows would need some sort of support with Active Directory. > * it seems likely (i'll do it if nobody else does) that we'll hoist the > DNS code out of net/ into it's own package(s) and potentially flesh out > some sort of resolver interface; i already have code (real code, not > toys) that would like to get TXT records DNS tends to be in its own package for precisely this reason. > * most people (waving hands about furiously) probably use defaults (or > compat) settings for hosts so checking hosts then dns would work in > those cases, for others we can leave this as an open issue to revisit > once we have more feedback and more of a chance to think about how this > should work In every case I've been in, hosts then dns is what works. I've never had the occasion or need to use nsswitch or nscd. The only reason I bring them up is because if people are writing high performance network applications in Go, any gains on DNS are likely to be seen. --dho
Sign in to reply to this message.
2009/12/26 Chris Wedgwood <cw@f00f.org>: > On Sun, Dec 27, 2009 at 04:13:08AM +0000, yves.junqueira@gmail.com wrote: > >> Properly capitalize and add ending periods to your comments. They >> must be proper English sentences. > > ack > >> rsc mentioned in a private email that he wanted as less dependencies as >> possible in the 'net' package. I don't know if io/ioutil could be a >> problem. > > it could be changed easily enough, io is used right now, it's not > clear ioutil is much 'worse' If dns was moved out of pkg/net, that would be ok, in my opinion. --dho
Sign in to reply to this message.
> If dns was moved out of pkg/net, that would be ok, in my opinion. i don't see how to do that. net.Dial needs dns and dns needs net.Dial.
Sign in to reply to this message.
On 2010/01/05 22:53:46, rsc wrote: > > If dns was moved out of pkg/net, that would be ok, in my opinion. > > i don't see how to do that. > net.Dial needs dns and dns needs net.Dial. Hm, that's true. I can't figure out a way to change that either, unfortunately.
Sign in to reply to this message.
|