Hi Martin, I don’t think this is the right direction. Network.framework is only different in that we have two parts of the preconnection—we split it into NWEndpoint and NWParameters.
Your second option “abolish, and just send them at connection time” is really just what we’re doing today with the preconnection. Really, just think of it as a struct that bundles all of the parameters, rather than having a list of 50 parameters to pass to Initiate. The only thing it is is a convenient bundle. I don’t think there’s anything actually to do at runtime. The API doc says that the error only gets thrown when you try to initiate with a bad preconnection. Thanks, Tommy > On Jun 16, 2021, at 2:58 PM, Martin Duke <[email protected]> wrote: > > 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
_______________________________________________ Taps mailing list [email protected] https://www.ietf.org/mailman/listinfo/taps
