On Tue, 13 Mar 2007 16:23:23 +0900, JINMEI Tatuya / 神明達哉 <[EMAIL PROTECTED]> wrote: > I thought I also pointed out > the available space might not be that large since it's an 'int' field > (which may be 16-bit long).
Wow... is there any implementation with a 16-bits ai_flags ? > (The "abuse" aspect of the issue is not resolved even with ai_eflags, > though, so I'm personally not 100% happy with the current > specification). > > Regarding the example that would be broken by the extension to the > addrinfo structure, it seems to me artificial and very rare (if it > ever happens). LibVLC 0.8.x (backend library to VLC media player) does exactly that in its getaddrinfo wrapper, for the exact same purpose (i.e. apply application-specific configurable IP version policy). I've now changed the code to only allow "known" flags, but I can't fix older releases. Another common case for wrapping and modifying hints has been the use of different protocols (SCTP, DCCP, UDP-Lite...) that are typically not accepted by getaddrinfo() implementations. Though to be fair, this is most often a single program, so there should be no version mixups. Did anyone ask for feedback from POSIX people? I think getaddrinfo() originally comes from there, right? > It's not surprising that the extension is unfriendly > with some tricky usage, but IMO the point is whether the benefit of > the extension outweighs the possible breakages. I'm actually not > sure if I have a clear opinion on it; on one had, the breakage > example given so far looks artificial as I said above (so a concrete > example of an existing application would be helpful if it exists). > On the other hand, I don't see much benefit in this extension either, > because, as far as I can see, only very few and special type of > applications want to use it. I'd personnaly love to have a replacement for getaddrinfo() that allows optional selection of a source address (with two real extra hostname and service name parameter) and returns a source address in the structure. One use case was SSM multicast (where you must resolve both source and group address); another case is if the user insists on using a specific source address. Currently, I have to make two getaddrinfo() calls, and make some loop among both lists (and assume that won't break any policy). That would also solve the IPv6 preference policy, with the added bonus that you don't have to setsockopt() in addition to getaddrinfo(), and don't have to do source address selection twice (once in getaddrinfo and once in connect). But I understand that way beyond the scope of this document. -- Rémi Denis-Courmont http://www.remlab.net/ -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 --------------------------------------------------------------------
