[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.

   Erik