From owner-freebsd-arch Mon Sep 10 7:15:29 2001 Delivered-To: freebsd-arch@freebsd.org Received: from amsfep15-int.chello.nl (amsfep15-int.chello.nl [213.46.243.27]) by hub.freebsd.org (Postfix) with ESMTP id 9D8B837B405 for ; Mon, 10 Sep 2001 07:15:22 -0700 (PDT) Received: from daemon.chronias.ninth-circle.org ([62.163.96.180]) by amsfep15-int.chello.nl (InterMail vM.5.01.03.06 201-253-122-118-106-20010523) with ESMTP id <20010910141225.VBZR12294.amsfep15-int.chello.nl@daemon.chronias.ninth-circle.org>; Mon, 10 Sep 2001 16:12:25 +0200 Received: (from asmodai@localhost) by daemon.chronias.ninth-circle.org (8.11.3/8.11.3) id f8AEAPH84767; Mon, 10 Sep 2001 16:10:25 +0200 (CEST) (envelope-from asmodai) Date: Mon, 10 Sep 2001 16:10:25 +0200 From: Jeroen Ruigrok/Asmodai To: Bill Fenner Cc: jlemon@flugsvamp.com, arch@freebsd.org Subject: Re: Causing to depend on Message-ID: <20010910161025.H67566@daemon.ninth-circle.org> References: <200109072125.OAA25298@windsor.research.att.com> <3B9A134D.3B31C443@mindspring.com> <200109081858.LAA12165@windsor.research.att.com> <20010908141005.R20137@prism.flugsvamp.com> <200109082022.NAA13321@windsor.research.att.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <200109082022.NAA13321@windsor.research.att.com> User-Agent: Mutt/1.3.19i Organisation: Ninth-Circle Enterprises Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG -On [20010908 22:26], Bill Fenner (fenner@research.att.com) wrote: > >>It seems that the real problem here is that sockaddr_storage is supposed >>to be protocol-neutral (used for appletalk, IPX, etc), but what your >>code really wants is IP-specific sockaddr_storage. > >Well, sockaddr_storage was introduced to support IPv6; it was defined >to be "at least large enough to accommodate sockaddr_in and sockaddr_in6 >and possibly other protocol specific socket addresses too." [RFC 2553 >section 3.10]. I guess the "and possibly other..." part is what's not >working out, especially since IEEE Std 1003.1-200x gets rid of the "possibly" >part. To help people following this thread: ``The header shall define the sockaddr_storage structure. This structure shall be: * Large enough to accommodate all supported protocol-specific address structures * Aligned at an appropriate boundary so that pointers to it can be cast as pointers to protocol-specific address structures and used to access the fields of those structures without alignment problems The sockaddr_storage structure shall contain at least the following members: sa_family_t ss_family When a sockaddr_storage structure is cast as a sockaddr structure, the ss_family field of the sockaddr_storage structure shall map onto the sa_family field of the sockaddr structure. When a sockaddr_storage structure is cast as a protocol-specific address structure, the ss_family field shall map onto a field of that structure that is of type sa_family_t and that identifies the protocol's address family.'' Courtesy latest POSIX draft. Also interesting as background: http://www.usenix.org/publications/library/proceedings/usenix2000/freenix/metzprotocol/metzprotocol_html/node10.html The above is part of a paper on protocol-independent networking programming for BSD sockets based on the latest standards. In effect this means that all AF_* address families should be able to be supported. -- Jeroen Ruigrok van der Werven/Asmodai asmodai@[wxs.nl|freebsd.org|xmach.org] Documentation nutter/C-rated Coder, finger asmodai@ninth-circle.dnsalias.net http://www.freebsd.org/doc/en_US.ISO8859-1/books/developers-handbook/ Reincarnate and play the game again, and again, and again... To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message