> > nope, the app. the stack doesn't know whether the app prefers stability > > or efficiency, unless the app tells it which it prefers. but at least > > the app probably has an idea which one is better. > > The app developer often doesn't know these things either -- if the app > understands this new API at all, I think it'd most often end up as a user > knob, meaning we could just call it a stack option and leave the app out of > things entirely. at least some apps do know these things. a web browser, for instance, understands that its TCP connections are ephemeral, and it knows how to recover from broken connections. same thing for an SMTP MTA or a mail reader. OTOH an interactive login using ssh is probably better off using stable addresses, as is an NFS mount. however if the API exists then nothing prevents the app from having a knob that lets the user override the default. > Which is harder, having the stack give the app a list of source and > destination addresses and then expect the app to figure out which to use, or > have the stack attempt various combinations of source and destination > addresses and just notify the application which one(s) worked? from experience, the delay in the latter case is often unacceptable, and even if it isn't, the stack often makes the wrong choice for the app. > Something tells me the latter is both easier and more likely to be > implemented correctly. you're simply wrong about that. Keith