Michael and I have been having a good github discussion <https://github.com/ietf-tapswg/api-drafts/issues/859> about preconnections and it has refined my thinking on this subject.
*Tommy*: do I read correctly that NetworkFramework doesn't have a notion of preconnections? *TL;DR* the preconnection concept is currently quite heavyweight and conceptually messy for not achieving very much. We should either give it more to do, or get rid of it. *Current design*: at the last interim, I believe we converged on the following. 1. Create preconn with endpoints and properties: do not deep copy, just store a preference 2. The preconn validates that the properties are satisfiable with an available stack and just stores the rest 3. Create connection from the preconn: build the candidate tree, resolve names, start racing. Note that because the properties may have changed, the minimal validation in #2 has to occur again. 4. The connection deep-copies all the necessary stuff. In other words, the *only* value add for the preconnection is a check that has to be repeated anyway at connection time. *The simplest fix* would be to do a deep copy at preconnection time. However, this implies two deep copies, which is expensive. Instead, I think we should do one of two things: 1) Beef up the preconnection: take all the endpoint and property data and do as much work as possible. Build the candidate tree up to the point of resolving names (and maybe even do that!). Obviously, this requires a deep copy at preconnection time, but I believe these data structures would no longer be necessary in the connection itself, so there would still be only one copy. 2) Abolish the preconnection. If all of these arguments aren't being used until connection time, why not just send them to TAPS at connection time? What do others think about this?
_______________________________________________ Taps mailing list [email protected] https://www.ietf.org/mailman/listinfo/taps
