Le lundi 23 octobre 2006 11:35, Julien Laganier a écrit : > But this is specified (and somehow discouraged) in the > Appendix: Doing per packet address selection would > certainly be costly because running the algorithm > isn't as cheap as setting a field in a packet.
It surely is more expensive that a sticky option, but it is definitely much less expensive that resetting the sticky option at each send. It's ok by me if it's discouraged, as long as it is specified, in case it really is needed. > > More seriously, there are some design flaws in the > > proposed getaddrinfo() extensions: > > > > For a start, there is a race condition if the > > locally available addresses or the routing table > > change between the getaddrinfo() invocation and > > connect() calls, we may get unwanted results. > > Yes there might be race conditions; that is however not > specific to the use of getaddrinfo() while expressing > address selection preferences. > > > Maybe a solution would be to return ai_bindaddr and > > ai_connaddr instead of just ai_addr. > One goal of this API is to be preserve the existing > basic IPv6 socket API. Expanding a structure breaks the API already. > Besides, I don't understand how would ai_connaddr and > ai_bindaddr solve the issue you describe. It makes sure the source address that will actually be bound in the one that was selected by getaddrinfo(). > It should never be assumed (by application, library > kernel...) that the ai_eflags field is present in a > struct addrinfo if the struct doesn't have the > AI_PREFERENCES flag set in its ai_flags field. IMHO, that's an ugly hack. It breaks the ABI. > Hence a buffer overflow shouldn't happen unless the > library of you scenario is broken. Sure, but that does not solve my problem. In fact buffer overflow will happen in even less obvious ways. If some function compiled against the new ABI memset() an addrinfo pointer to a structure allocated by a function built with the old ABI, you have a buffer overflow, and well, you can't test for AI_PREFERENCES, since you don't even know it exists. Very bad idea. Changing a struct storage size is always a very bad idea. Why do you think people invented struct sockaddr_storage instead of increasing the size of struct sockaddr when rolling out the IPv6 API? > > IMHO, it might be wiser to define extended > > getaddrinfo, freeaddrinfo and struct addrinfo > > variants (geteaddrinfo ?) - that woud allow to use > > the ai_bindaddr and ai_connaddr thing at the same > > time. > IMHO it's nice to avoid introducing yet another name > resolution primitive. Regarding ai_bindaddr and > ai_connaddr, see my comment above. I don't see any point in sparing extra primitive and structure names. I think that it is much nicer than partially breaking the ABI by changing the size of structure. -- Rémi Denis-Courmont
pgp2GogNCrRjc.pgp
Description: PGP signature
-------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 --------------------------------------------------------------------
