jiebi/CodeConvo huggingface dataset:
The Rendezvous() Action causes the Preconnection to listen on the Local Endpoint for an incoming Connection from the Remote Endpoint, <del> while simultaneously trying to establish a Connection from the Local Endpoint to the Remote Endpoint.  This corresponds to a TCP simultaneous open, for example. </del> <ins> while also simultaneously trying to establish a Connection from the Local Endpoint to the Remote Endpoint. If there are multiple Local Endpoints or Remote Endpoints configured, then initiating a rendezvous action will systematically probe the reachability of those endpoints following an approach such as that used in Interactive Connectivity Establishment (ICE) RFC5245. If the endpoints are suspected to be behind a NAT, Rendezvous() can be initiated using Local and Remote Endpoints that support a method of discovering NAT bindings such as Session Traversal Utilities for NAT (STUN) RFC8489 or Traversal Using Relays around NAT (TURN) RFC5766.  In this case, the Local Endpoint will resolve to a mixture of local and server reflexive addresses.  The Resolve() action on the Preconnection can be used to discover these bindings: The Resolve() call returns a list of Preconnection Objects, that represent the concrete addresses, local and server reflexive, on which a Rendezvous() for the Preconnection will listen for incoming Connections.  These resolved Preconnections will share all other Properties with the Preconnection from which they are derived, though some Properties may be made more-specific by the resolution process. An application that uses Rendezvous() to establish a peer-to-peer connection in the presence of NATs will configure the Preconnection object with a Local Endpoint that supports NAT binding discovery.  It will then Resolve() on that endpoint, and pass the resulting list of candidate local addresses to the peer via a signalling protocol, for example as part of an ICE RFC5245 exchange within SIP RFC3261 or WebRTC RFC7478.  The peer will, via the same signalling channel, return the remote endpoint candidates.  These remote endpoint candidates are then configured on the Preconnection, allowing the Rendezvous() Action to be initiated. </ins> The Rendezvous() Action returns a Connection object.  Once Rendezvous() has been called, any changes to the Preconnection MUST
other, and become part of a Connection Group.  Calling Clone on any of these Connections adds another Connection to the Connection Group, and so on.  "Entangled" Connections share all Connection Properties <del> except "Priority (Connection)", see conn-priority.  Like all other Properties, Priority is copied to the new Connection when calling Clone(), but it is not entangled: Changing Priority on one Connection does not change it on the other Connections in the same Connection Group. </del> <ins> except "Connection Priority", see conn-priority.  Like all other Properties, Connection Priority is copied to the new Connection when calling Clone(), but it is not entangled: Changing Connection Priority on one Connection does not change it on the other Connections in the same Connection Group. </ins> It is also possible to check which Connections belong to the same Connection Group.  Calling GroupedConnections() on a specific
Attempts to clone a Connection can result in a CloneError: <del> The Connection Property "Priority" operates on entangled Connections as in msg-priority: when allocating available network capacity among Connections in a Connection Group, sends on Connections with higher Priority values will be prioritized over sends on Connections with lower Priority values.  A transport system implementation should, if possible, assign each Connection the capacity share (M-N) x C / M, where N is the Connection's Priority value, M is the maximum Priority value used by all Connections in the group and C is the total available capacity.  However, this Priority setting is purely advisory, and provides no guarantees about the way capacity is shared.  Each implementation is free to implement a way to share capacity that it sees fit. </del> <ins> The Connection Priority Connection Property operates on entangled Connections using the same approach as in msg-priority: when allocating available network capacity among Connections in a Connection Group, sends on Connections with lower Priority values will be prioritized over sends on Connections with higher Priority values.  Capacity will be shared among these Connections according to the Connection Group Transmission Scheduler property (conn- scheduler).  See priority-in-taps for more. </ins> 7.
will not result in a SendError separate from the InitiateError signaling the failure of Connection establishment. <ins> 8.2.7. The Transport Services interface provides two properties to allow a sender to signal the relative priority of data transmission: the Priority Message Property msg-priority, and the Connection Priority Connection Property conn-priority.  These properties are designed to allow the expression and implementation of a wide variety of approaches to transmission priority in the transport and application layer, including those which do not appear on the wire (affecting only sender-side transmission scheduling) as well as those that do (e.g.  I-D.ietf-httpbis-priority. A Transport Services system gives no guarantees about how its expression of relative priorities will be realized; for example, if a transport stack that only provides a single in-order reliable stream is selected, prioritization information can only be ignored. However, the Transport Services system will seek to ensure that performance of relatively-prioritized connections and messages is not worse with respect to those connections and messages than an equivalent configuration in which all prioritization properties are left at their defaults. The Transport Services interface does order Connection Priority over the Priority Message Property.  In the absense of other externalities (e.g., transport-layer flow control), a priority 1 Message on a priority 0 Connection will be sent before a priority 0 Message on a priority 1 Connection in the same group. </ins> 8.3. Once a Connection is established, it can be used for receiving data
to an inbound SYN with a SYN-ACK. Calling "Clone" on a TCP Connection creates a new Connection with <del> equivalent parameters.  The two Connections are otherwise independent. </del> <ins> equivalent parameters.  These Connections, and Connections generated via later calls to "Clone" on one of them, form a Connection Group.  To realize "entanglement" for these Connections, with the exception of "Connection Priority", changing a Connection Property on one of them must affect the Connection Properties of the others too.  No guarantees of honoring the Connection Property "Connection Priority" are given, and thus it is safe for an implementation of a transport system to ignore this property.  When it is reasonable to assume that Connections traverse the same path (e.g., when they share the same encapsulation), support for it can also experimentally be implemented using a congestion control coupling mechanism (see for example TCP-COUPLING or RFC3124). </ins> SEND.TCP.  TCP does not on its own preserve Message boundaries. Calling "Send" on a TCP connection lays out the bytes on the TCP
If this is the only Connection object that is assigned to the SCTP association or stream mapping has not been negotiated, <del> CONNECT.SCTP is called.  Else, a new stream is used: if there are enough streams available, "Initiate" is just a local operation that assigns a new stream number to the Connection object.  The number of streams is negotiated as a parameter of the prior CONNECT.SCTP call, and it represents a trade-off between local resource usage and the number of Connection objects that can be mapped without requiring a reconfiguration signal.  When running out of streams, ADD_STREAM.SCTP must be called. </del> <ins> CONNECT.SCTP is called.  Else, unless the Selection Property "activeReadBeforeSend" is Preferred or Required, a new stream is used: if there are enough streams available, "Initiate" is just a local operation that assigns a new stream number to the Connection object.  The number of streams is negotiated as a parameter of the prior CONNECT.SCTP call, and it represents a trade-off between local resource usage and the number of Connection objects that can be mapped without requiring a reconfiguration signal.  When running out of streams, ADD_STREAM.SCTP must be called. </ins> If this is the only Connection object that is assigned to the SCTP association or stream mapping has not been negotiated,
be sent in multiple parts. Protocols that provide the framing (such as length-value protocols, <del> or protocols that use delimiters) provide data boundaries that may be longer than the typical datagram.  Each Message for framing protocols </del> <ins> or protocols that use delimiters) may support Message sizes that do not fit within a single datagram.  Each Message for framing protocols </ins> corresponds to a single frame, which may be sent either as a complete <del> Message, or in multiple parts. </del> <ins> Message in the underlying protocol, or in multiple parts. </ins> 5.1.
5.4. <del> Entangled Connections can be created using the Clone Action: Calling Clone on a Connection yields a group of Connections: the parent Connection on which Clone was called, and a resulting cloned Connection.  The new Connection is actively openend, and it will send a Ready Event or an EstablishmentError Event.  The Connections within a group are "entangled" with each other, and become part of a Connection Group.  Calling Clone on any of these Connections adds another Connection to the Connection Group, and so on.  "Entangled" Connections share all Connection Properties except "Connection Priority" (see conn-priority) .  Like all other Properties, Connection Priority is copied to the new Connection when calling Clone(), but it is not entangled: Changing Connection Priority on one Connection does not change it on the other Connections in the same Connection Group. The stack of Message Framers associated with a Connection are also copied to the cloned Connection when calling Clone.  In other words, a cloned Connection has the same stack of Message Framers as the Connection from which they are Cloned, but these Framers may internally maintain per-Connection state. </del> <ins> Connection Groups can be created using the Clone Action: Calling Clone on a Connection yields a Connection Group containing two Connections: the parent Connection on which Clone was called, and a resulting cloned Connection.  The new Connection is actively openend, and it will send a Ready Event or an EstablishmentError Event.  Calling Clone on any of these Connections adds another Connection to the Connection Group.  Connections in a Connection Group share all Connection Properties except "Connection Priority" (see conn-priority), and these Connection Properties are entangled: Changing one of the Connection Properties on one Connection in the Connection Group automatically changes the Connection Property for all others.  For example, changing "Timeout for aborting Connection" (see conn-timeout) on one Connection in a Connection Group will automatically make the same change to this Connection Property for all other Connections in the Connection Group.  Like all other Properties, "Connection Priority" is copied to the new Connection when calling Clone(), but in this case, a later change to the "Connection Priority" on one Connection does not change it on the other Connections in the same Connection Group. Message Properties are also not entangled.  For example, changing "Lifetime" (see msg-lifetime) of a Message will only affect a single Message on a single Connection. A new Connection created by Clone can have a Message Framer assigned via the optional "framer" parameter of the Clone Action.  If this parameter is not supplied, the stack of Message Framers associated with a Connection is copied to the cloned Connection when calling Clone.  Then, a cloned Connection has the same stack of Message Framers as the Connection from which they are Cloned, but these Framers may internally maintain per-Connection state. </ins> It is also possible to check which Connections belong to the same Connection Group.  Calling GroupedConnections() on a specific
is just a new stream of an already active multi-streaming protocol instance. <del> Changing one of the Connection Properties on one Connection in the group changes it for all others.  Message Properties, however, are not entangled.  For example, changing "Timeout for aborting Connection" (see conn-timeout) on one Connection in a group will automatically change this Connection Property for all Connections in the group in the same way.  However, changing "Lifetime" (see msg- lifetime) of a Message will only affect a single Message on a single Connection, entangled or not. </del> If the underlying protocol supports multi-streaming, it is natural to <del> use this functionality to implement Clone.  In that case, entangled Connections are multiplexed together, giving them similar treatment not only inside endpoints, but also across the end-to-end Internet path. </del> <ins> use this functionality to implement Clone.  In that case, Connections in a Connection Group are multiplexed together, giving them similar treatment not only inside endpoints, but also across the end-to-end Internet path. </ins> Note that calling Clone() can result in on-the-wire signaling, e.g., <del> to open a new connection, depending on the underlying Protocol Stack. When Clone() leads to multiple connections being opened instead of multi-streaming, the Transport Services system will ensure consistency of Connection Properties by uniformly applying them to all underlying connections in a group.  Even in such a case, there are possibilities for a Transport Services system to implement prioritization within a Connection Group TCP-COUPLING RFC8699. </del> <ins> to open a new transport connection, depending on the underlying Protocol Stack.  When Clone() leads to the opening of multiple such connections, the Transport Services system will ensure consistency of Connection Properties by uniformly applying them to all underlying connections in a group.  Even in such a case, there are possibilities for a Transport Services system to implement prioritization within a Connection Group TCP-COUPLING RFC8699. </ins> Attempts to clone a Connection can result in a CloneError: <del> The Connection Priority Connection Property operates on entangled Connections using the same approach as in msg-priority: when allocating available network capacity among Connections in a </del> <ins> The "Connection Priority" Connection Property operates on Connections in a Connection Group using the same approach as in msg-priority: when allocating available network capacity among Connections in a </ins> Connection Group, sends on Connections with lower Priority values will be prioritized over sends on Connections with higher Priority values.  Capacity will be shared among these Connections according to
When set to true, this property will initiate new Connections using as little cached information (such as session tickets or cookies) as <del> possible from previous connections that are not entangled with it. Any state generated by this Connection will only be shared with entangled connections.  Cloned Connections will use saved state from within the Connection Group.  This is used for separating Connection Contexts as specified in I-D.ietf-taps-arch. </del> <ins> possible from previous connections that are not in the same Connection Group.  Any state generated by this Connection will only be shared with Connections in the same Connection Group.  Cloned Connections will use saved state from within the Connection Group. This is used for separating Connection Contexts as specified in I- D.ietf-taps-arch. </ins> Note that this does not guarantee no leakage of information, as implementations may not be able to fully isolate all caches (e.g.
example, if reliable delivery was requested for a Message handed over before calling Close, the Closed Event will signify that this Message has indeed been delivered.  This action does not affect any other <del> Connection that is entangled with this one in a Connection Group. </del> <ins> Connection in the same Connection Group. </ins> The Closed Event informs the application that the Remote Endpoint has closed the Connection.  There is no guarantee that a remote Close will indeed be signaled. Abort terminates a Connection without delivering any remaining <del> Messages.  This action does not affect any other Connection that is entangled with this one in a Connection Group. </del> <ins> Messages.  This action does not affect any other Connection that in the same Connection Group. </ins> CloseGroup gracefully terminates a Connection and any other <del> Connections that are entangled with this one in a Connection Group. For example, all of the Connections in a group might be streams of a single session for a multistreaming protocol; closing the entire group will close the underlying session.  See also groups.  As with Close, any Messages remaining to be processed on a Connection will be handled prior to closing. AbortGroup terminates a Connection and any other Connections that are entangled with this one in a Connection Group without delivering any remaining Messages. </del> <ins> Connections in the same Connection Group.  For example, all of the Connections in a group might be streams of a single session for a multistreaming protocol; closing the entire group will close the underlying session.  See also groups.  As with Close, any Messages remaining to be processed on a Connection will be handled prior to closing. AbortGroup terminates a Connection and any other Connections in the same Connection Group without delivering any remaining Messages. </ins> A ConnectionError informs the application that: 1) data could not be delivered to the peer after a timeout, or 2) the Connection has been
during Connection establishment.  This Message can potentially be received multiple times (i.e., multiple copies of the message data may be passed to the Remote Endpoint).  See also msg- <del> safelyreplayable.  Note that disabling this property has no effect for protocols that are not connection-oriented and do not protect against duplicated messages, e.g., UDP. </del> <ins> safelyreplayable. </ins> 4.2.6.
Session cache management: Used to tune session cache capacity, lifetime, and other policies. <ins> Connections that use Transport Services SHOULD use security in general.  However, for compatibility with endpoints that do not support transport security protocols (such as a TCP endpoint that does not support TLS), applications can initialize their security parameters to indicate that security can be disabled, or can be opportunistic.  If security is disabled, the Transport Services system will not attempt to add transport security automatically.  If security is opportunistic, it will allow Connections without transport security, but will still attempt to use security if available. </ins> Representation of Security Parameters in implementations should parallel that chosen for Transport Property names as recommended in scope-of-interface-defn.
A Preconnection Object holds properties reflecting the application's requirements and preferences for the transport.  These include Selection Properties for selecting protocol stacks and paths, as well <del> as Connection Properties for configuration of the detailed operation of the selected Protocol Stacks. </del> <ins> as Connection Properties and Message Properties for configuration of the detailed operation of the selected Protocol Stacks on a per- Connection and Message level. </ins> The protocol(s) and path(s) selected as candidates during establishment are determined and configured using these properties.
"Connection Priority" on one Connection does not change it on the other Connections in the same Connection Group. <del> Message Properties are also not entangled.  For example, changing "Lifetime" (see msg-lifetime) of a Message will only affect a single Message on a single Connection. </del> <ins> Message Properties set on a Connection also apply only to that Connection. </ins> A new Connection created by Clone can have a Message Framer assigned via the optional "framer" parameter of the Clone Action.  If this
Sending a Message with Message Properties inconsistent with the Selection Properties of the Connection yields an error. <del> Connection Properties describe the default behavior for all Messages on a Connection.  If a Message Property contradicts a Connection Property, and if this per-Message behavior can be supported, it overrides the Connection Property for the specific Message.  For example, if "Reliable Data Transfer (Connection)" is set to "Require" and a protocol with configurable per-Message reliability is used, setting "Reliable Data Transfer (Message)" to "false" for a particular Message will allow this Message to be sent without any reliability guarantees.  Changing the Reliable Data Transfer property on Messages is only possible for Connections that were established enabling the Selection Property "Configure Per-Message Reliability". </del> <ins> If a Message Property contradicts a Connection Property, and if this per-Message behavior can be supported, it overrides the Connection Property for the specific Message.  For example, if "Reliable Data Transfer (Connection)" is set to "Require" and a protocol with configurable per-Message reliability is used, setting "Reliable Data Transfer (Message)" to "false" for a particular Message will allow this Message to be sent without any reliability guarantees.  Changing the Reliable Data Transfer property on Messages is only possible for Connections that were established enabling the Selection Property "Configure Per-Message Reliability". </ins> The following Message Properties are supported:
IP address (IPv4 or IPv6 address): <del> Interface name (string): </del> <ins> Interface name (string), e.g., to qualify link-local or multicast addresses (see ifspec for details): </ins> Note that an IPv6 address specified with a scope (e.g. "2001:db8:4920:e29d:a420:7461:7073:0a%en0") is equivalent to
6.1.2. <ins> Note that this API has multiple ways to constrain and prioritize endpoint candidates based on the network interface: Specifying an interface on a RemoteEndpoint qualifies the scope of the remote endpoint, e.g., for link-local addresses. Specifying an interface on a LocalEndpoint explicitly binds all candidates derived from this endpoint to use the specified interface. Specifying an interface using the "interface" Selection Property (prop-interface) or indirectly via the "pvd" Selection Property (prop-pvd) influences the selection among the available candidates. While specifying an interface on an endpoint restricts the candidates available for connection establishment in the Pre-Establishment Phase, the Selection Properties prioritize and constrain the connection establishment. 6.1.3. </ins> An Endpoint can have an alternative definition when using different protocols.  For example, a server that supports both TLS/TCP and QUIC may be accessible on two different port numbers depending on which
Interface name (string): <ins> Note that an IPv6 address specified with a scope (e.g. "2001:db8:4920:e29d:a420:7461:7073:0a%en0") is equivalent to "WithIPv6Address" with an unscoped address and "WithInterface " together. </ins> An Endpoint cannot have multiple identifiers of a same type set. That is, an endpoint cannot have two IP addresses specified.  Two separate IP addresses are represented as two Endpoint Objects.  If a
the other hand, the Remote Endpoint specifies a hostname but no addresses, the Connection can perform name resolution and attempt using any address derived from the original hostname of the Remote <del> Endpoint. </del> <ins> Endpoint.  Note that multiple Remote Endpoints can be added to a Preconnection, as discussed in add-endpoints. </ins> The Transport Services system resolves names internally, when the Initiate(), Listen(), or Rendezvous() method is called to establish a