[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Second shim
Brian E Carpenter wrote:
Erik Nordmark wrote:
So while the application didn't specify it, and a "shim" or some new
connect-by-name API can cycle through, it still will be a bit
inefficient if you let TCP try things (for a single <source, dest>)
and timing out before trying the next one.
Yes, but quite tolerable for some applications (Lotus Notes seems to have
done something very much like this for years, for example, and it's
just fine for background replication).
I do wonder whether this isn't a distraction right now, though. It should
certainly be orthogonal to the IP layer shim.
The question we asked ourselves at the interim meeting was whether the
shim protocol needed some mechanism to facilitate solving the above
problem above the shim layer. I think our conclusion is that if we can
carry a ULID-pair option in the context establishment messages (I1 etc)
then one can use the shim capability for these purposes (basically, to
verify whether the ULID is reachable at a particular locator) as part
of some TBD API.
So in terms of getting the protocol spec finished I don't think we need
to worry (any more) about this.