Subject: Re: RPC and ipv6
To: Frank van der Linden <firstname.lastname@example.org>
From: None <email@example.com>
Date: 12/08/1999 11:34:26
>As RFC 2553 suggests, sockaddr_in usage should be replaced by
>sockaddr_storage to make code more protocol independent. This means
>an interface change. This can't be avoided in case of the SVCXPRT
>change. Basically there are 2 options:
> a) Go for struct sockaddr_storage completely, including in the
> interface. Use versioning for the old interface for backward
> b) Only use struct sockaddr_storage inside SVCXPRT (and use
> versioning there too), but do not change the sockaddr_in *
> paramemeters. Rely on the application to check for address
> family and do the right thing.
>I prefer a), but it does mean that any source code using the RPC
>library calls won't compile anymore, and needs to be modified.
>Solaris 8 seems to have kept the old interface. Disadvantage is
>that this may lead to source code compiling, but crashing because
>an address may resolve to an ipv6 address, not fitting in the
>sockaddr_in structure it passed a pointer to. I'd rather have
>the failure at compile time.
I believe compatibility with other source is the most important thing,
so if I were you I would make plans on route (a) and talk with Solaris
guys (where is the standardization body for RPC API?).
using "struct sockaddr_storage *" does not seem right to me. using
"struct sockaddr *" and separate "int len" is the way to go.
("int len" is needed for Solaris and Linux, where sa_len is not given)