Re: Transport level multihoming

[Brian E Carpenter <brian@hursley.ibm.com>]

Greg Maxwell wrote:
> 
> On Tue, 7 Aug 2001, Brian E Carpenter wrote:
> 
> [snip]
> > On the other hand we know that major restructuring of applications isn't going
> > to happen - that's the real world. So if we have to do work in the transport
> > layer, the transport layer is going to have to hide most of it below some
> > sort of socket API. I can't see any reason in principle why that API
> > would have to expose a bunch of addresses, even if it turns out that
> > multi6 requires more than one. A "primary" address per host would be enough
> > to expose to the middleware.
> 
> If the primary address is functional at connection setup time, then, yes
> it could learn the other transports from the remote end. However, what do
> you do if the primary is down? The only solutions I can think of either
> require the applications to rotate the address passed to the API, or
> require the transport to consult DNS (what an ugly kludge and layering
> violation THAT would be!).

There is *always* an abstraction layer above which a single handle identifies
the other party in a session (and probably no handle at all identifies
"this" end of the session). So whatever layer is the highest layer to
be aware of N addresses, there is always a layer above that (conceptually
at least) that has a single handle for that set of N addresses.

All I am saying is that this abstraction layer may just as well be a socket
API, and that single handle may just as well be one of the N addresses - and
if you do it that way, you minimise the impact on existing apps layer logic.

It's probably sloppy to write as I did of a "primary" address being the
handle; it's just an arbitrary choice among the N addresses available.
It's the one that gethostbyname (equivalent) chooses to return to you;
it might conceal a bunch of others from you below the socket API,
and use them as needed for multihoming or whatever other cookery it
needs to do.

   Brian