Thursday October 28, 2004

protocol independent name and service resolution As a member of the IPv6 team I worked on the basic and advanced IPv6 APIs. Both of these are updates of previous RFCs and as such contain a fair bit of already understood material. One aspect of the basic API which has existed since its first apperance in RFC 2133 but doesn't appear to be used as much as it should be is getaddrinfo(3SOCKET).

In the ancient past one might do something like:

    hp = gethostbyname(host, &res, buf, &h_error);
    if (hp == NULL) {
        return -1;
    }
    addrp = (struct in_addr **) hp->h_addr_list;
    ipv4_addr = (*addrp)->s_addr;

    memset((char *)&him4, 0, sizeof(struct sockaddr_in));
    him4.sin_port = htons(PORT);
    him4.sin_addr.s_addr = (uint32_t) htonl(ipv4_addr);
    him4.sin_family = AF_INET;

    len = sizeof(struct sockaddr_in);
    himP = &him4;

    if (connect(fd, (struct sockaddr *)himP, len) == -1) {
        return -1;
    }

And we didn't even lookup the service in all of that. getipnodebyname(3SOCKET) came along and allowed us to specify an address family but pretty much caused the same amount of pain as far as managing the address and the complete lack of help in looking up a service.

getaddrinfo(3SOCKET) wraps this up into a nice API which reduces the amount of work the programmer has to do while allowing control over the result.

    rc = getaddrinfo(nodename, servname, &hints, &res);
    if (rc != 0) {
        exit(EXIT_FAILURE);
    }

    for(r = res; r != NULL; r = r->ai_next) {
        fd = socket(r->ai_family, r->ai_socktype, r->ai_protocol);
        if (fd == -1) {
            continue;
        }
        if (connect(fd, r->ai_addr, r->ai_addrlen) == -1) {
            close(fd);
            continue;
        }
        close(fd);
    }

getaddrinfo(3SOCKET) allows the user to lookup a nodename and service returning a set of protocol independent address structures. Those can be used to build a socket and attempt communication without the programmer getting involved in the protocol details. The amount of grungy detail is reduced. Note the "hints" structure passed to getaddrinfo(3SOCKET)? Normally the address types and protocols used are those which make sense for the current context but if the programmer wants to specify contraints on what is returned he can do that in the hints structure. Further information is available on the getaddrinfo(3SOCKET) man page. ( Oct 28 2004, 04:17:35 PM PDT ) Permalink

daily SMF Tobin and Stephen Hahn have been writting about SMF a fair bit lately. I didn't have anything to do with the development of SMF but I do have to work with the new management framework. Today I was bringing up a new machine and ran across a service issue. After getting the machine up and upgrading it from some pre SMF image to a very recent one nis wasn't coming up.

# ps -ef | grep ypbind
    root 100455 100218   0 15:00:41 console     0:00 grep ypbind
# svcs | grep nis
maintenance    15:00:06 svc:/network/nis/client:default
# svcs -d network/nis/client
STATE          STIME    FMRI
disabled       14:59:46 svc:/network/nis/server:default
online         14:59:49 svc:/system/filesystem/minimal:default
online         14:59:56 svc:/system/identity:domain
online         15:00:06 svc:/network/rpc/bind:default
# svcadm enable network/nis/server
# Oct 28 15:01:15 ipng60 svc.startd[100004]: network/nis/server:default misconfigured
# cd /var/svc/log
# ls *nis*
network-nis-client:default.log  network-nis-server:default.log
# cat network-nis-server:default.log 
[ Oct 28 15:01:15 executing start method ("/lib/svc/method/yp") ]
/lib/svc/method/yp: domain directory missing
[ Oct 28 15:01:15 Method "start" exited with status 96 ]

So in a few short commands I figured out what was wrong and went on to correct it. ( Oct 28 2004, 04:00:24 PM PDT ) Permalink Comments [4]