>> In general, bind(2) it before connect(2)ing. > That can work, provided the application supports it, but is really a > terrible solution -
Unfortunately I think it's the only solution, not only just because we don't have any APIs more sophisicated but because it's not an easy problem. > the application doesn't really care which address gets used, just the > type of address. Perhaps, but "type" is somewhat ill-defined here. One application's idea of address type doesn't necessarily match the next's. One may prefer "site-local reachable over this VPN tunnel" over "globally routed" over "other site-local", as a simple example that is unlikely to match any notion of "type" that's likely to make it into an API. > A multi-homed host (which is getting to be far more common) wants > some applications to use temporary addresses, and others to use > stable addresses (and if we had them, perhaps others to use CGAs) ...and potentially other criteria, too complex to represent simply... > but doesn't really want to do all the work of selecting which > particular temporary address (ie: which outgoing interface) is the > appropriate one for each destination. The kernel already does that, > and selects an associated address, it should just continue doing > that. Trouble is, that's suitable only when the kernel's preference rules match the application's. Since different applications want different rules, the application has to control local address selection somehow. And I think we agree on that much. But it seems to me that an API that classifies addresses into some small number of types based on set-in-stone rules is going to be useful to too small a subset of applications to make it worth the various costs of adding it. I would prefer to do this in userland, with a library routine that fetches the list of addresses and selects one based on whatever criteria it wants, maybe even involving an application-provided callback. And, shouldn't this be on tech-net? /~\ The ASCII Mouse \ / Ribbon Campaign X Against HTML [email protected] / \ Email! 7D C8 61 52 5D E7 2D 39 4E F1 31 3E E8 B3 27 4B
