taps

type Config struct {
	Protocols []Protocol
	Services  []Service
}

type Connection struct {
	State enum.ConnectionState
	// Need to keep track of ConnPrio Property separately from the
	// other ConnectionProperties. Feedback welcome.
	ConnPrio uint
	// contains filtered or unexported fields
}

type ConnectionProperties struct {
	// RecvChecksumLen specifies the minimum number of bytes in a
	// received message that need to be covered by a checksum. A
	// special value of 0 means that a received packet does not
	// need to have a non-zero checksum field. A receiving
	// endpoint will not forward messages that have less coverage
	// to the application. The application is responsible for
	// handling any corruption within the non-protected part of
	// the message [RFC8085]. (See
	// https://www.ietf.org/archive/id/draft-ietf-taps-interface-13.html#section-8.1.1)
	RecvChecksumLen uint

	// ConnPrio is a non-negative integer representing the
	// relative inverse priority (i.e., a lower value reflects a
	// higher priority) of this Connection relative to other
	// Connections in the same Connection Group. It has no effect
	// on Connections not part of a Connection Group. This
	// property is not entangled when Connections are cloned,
	// i.e., changing the Priority on one Connection in a
	// Connection Group does not change it on the other
	// Connections in the same Connection Group. No guarantees of
	// a specific behavior regarding Connection Priority are
	// given; a Transport Services system may ignore this
	// property. (See
	// https://www.ietf.org/archive/id/draft-ietf-taps-interface-13.html#section-8.1.2)
	ConnPrio uint

	// ConnTimeout specifies how long to wait before deciding that
	// an active Connection has failed when trying to reliably
	// deliver data to the Remote Endpoint. Adjusting this
	// Property will only take effect when the underlying stack
	// supports reliability. A value of 0 means that no timeout is
	// scheduled. (See
	// https://www.ietf.org/archive/id/draft-ietf-taps-interface-13.html#section-8.1.3)
	ConnTimeout time.Duration

	// KeepAliveTimeout specifies the maximum length of time an
	// idle connection (one for which no transport packets have
	// been sent) should wait before the Local Endpoint sends a
	// keep-alive packet to the Remote Endpoint. Adjusting this
	// Property will only take effect when the underlying stack
	// supports sending keep-alive packets. Guidance on setting
	// this value for datagram transports is provided in
	// [RFC8085]. A value greater than ConnTimeout or the special
	// value 0 will disable the sending of keep-alive
	// packets. (See
	// https://www.ietf.org/archive/id/draft-ietf-taps-interface-13.html#section-8.1.4)
	KeepAliveTimeout time.Duration

	// ConnScheduler specifies which scheduler should be used
	// among Connections within a Connection Group. (See
	// https://www.ietf.org/archive/id/draft-ietf-taps-interface-13.html#section-8.1.5)
	ConnScheduler enum.StreamScheduler

	// ConnCapacityProfile specifies the desired network treatment
	// for traffic sent by the application and the tradeoffs the
	// application is prepared to make in path and protocol
	// selection to receive that desired treatment. When the
	// capacity profile is set to a value other than Default, the
	// Transport Services system SHOULD select paths and configure
	// protocols to optimize the tradeoff between delay, delay
	// variation, and efficient use of the available capacity
	// based on the capacity profile specified. (See
	// https://www.ietf.org/archive/id/draft-ietf-taps-interface-13.html#section-8.1.6)
	ConnCapacityProfile enum.CapacityProfile

	// MultipathPolicy specifies the local policy for transferring
	// data across multiple paths between the same end hosts if
	// Multipath is not set to Disabled in TransportProperty. (See
	// https://www.ietf.org/archive/id/draft-ietf-taps-interface-13.html#section-8.1.7)
	MultipathPolicy enum.MultipathPolicy

	// [Max|Min][Send|Recv]Rate specifies an upper-bound rate that
	// a transfer is not expected to exceed (even if flow control
	// and congestion control allow higher rates), and/or a
	// lower-bound rate below which the application does not deem
	// it will be useful. These are specified in bits per
	// second. The special value of 0 (alternatively: a Max Rate
	// set lower than the corresponding Min Rate) indicates that
	// no bound is specified.  (See
	// https://www.ietf.org/archive/id/draft-ietf-taps-interface-13.html#section-8.1.8)
	MinSendRate, MinRecvRate, MaxSendRate, MaxRecvRate uint

	// GroupConnLimit controls the number of Connections that can
	// be accepted from a peer as new members of the Connection's
	// group. Similar to SetNewConnectionLimit(), this limits the
	// number of ConnectionReceived Events that will occur, but
	// constrained to the group of the Connection associated with
	// this property. For a multi-streaming transport, this limits
	// the number of allowed streams. (See
	// https://www.ietf.org/archive/id/draft-ietf-taps-interface-13.html#section-8.1.9)
	GroupConnLimit uint

	// IsolateSession, when set, will initiate new Connections
	// using as little cached information (such as session tickets
	// or cookies) as 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. (See
	// https://www.ietf.org/archive/id/draft-ietf-taps-interface-13.html#section-8.1.10)
	IsolateSession bool
	// contains filtered or unexported fields
}

type Endpoint struct {
	Address   net.Addr
	Transport string
	Network   string
	Interface string
}

type EstablishmentError error

type Framer interface {
	Encode(kv map[string]interface{}, dst io.Writer, src io.Reader) (written int64, err error)
	Decode(kv map[string]interface{}, dst io.Writer, src io.Reader) (written int64, err error)
}

type HTTPMessageFramer struct {
	KeyValue map[string]string
}

type KeyPair struct {
	PrivateKey crypto.PrivateKey
	PublicKey  crypto.PublicKey
}

type Listener struct {
	Preconnection Preconnection
}

type LocalEndpoint struct{ Endpoint }

type Message struct {
	// MessageContext is an optional pointer to a context object
	// for this Message
	*MessageContext

	// Data provides access to the bytes that are to be sent OR
	// that have been received for this Message
	Data []byte

	// EndOfMessage is flag that indicates whether, for the
	// purposes of the underlying transport, this message has been
	// completely submitted for transmission OR whether it has
	// been completely received from the underlying connection
	EndOfMessage bool
}

type MessageContext struct {
	// MsgLifetime specifies how long a particular Message can
	// wait to be sent to the Remote Endpoint before it is
	// irrelevant and no longer needs to be (re-)transmitted. This
	// is a hint to the Transport Services system - it is not
	// guaranteed that a Message will not be sent when its
	// Lifetime has expired.
	//
	// See https://www.ietf.org/archive/id/draft-ietf-taps-interface-13.html#section-9.1.3.1
	MsgLifetime time.Duration

	// MsgPrio specifies the priority of a Message, relative to
	// other Messages sent over the same Connection.A Message with
	// Priority 0 will yield to a Message with Priority 1, which
	// will yield to a Message with Priority 2, and so
	// on. Priorities may be used as a sender-side scheduling
	// construct only, or be used to specify priorities on the
	// wire for Protocol Stacks supporting prioritization.
	//
	// See https://www.ietf.org/archive/id/draft-ietf-taps-interface-13.html#section-9.1.3.2
	MsgPrio uint

	// MsgOrdered, if true, preserves the order on delivery in
	// which Messages were originally submitted.
	//
	// Deprecated: The TAPS spec sets the default of this value to
	// "the queried Boolean value of the Selection Property
	// preserveOrder", but the latter is never actually in
	// scope/queriable when the MessageContext object is
	// created. Not setting the parameter defaults to "false",
	// which is indistinguishable from actively setting it to
	// "false". Feedback welcome.
	//
	// See https://www.ietf.org/archive/id/draft-ietf-taps-interface-13.html#section-9.1.3.3
	MsgOrdered bool

	// SafelyReplayable, if true, specifies that a Message is safe
	// to send to the Remote Endpoint more than once for a single
	// Send Action. It marks the data as safe for certain 0-RTT
	// establishment techniques, where retransmission of the 0-RTT
	// data may cause the remote application to receive the
	// Message multiple times.
	//
	// See https://www.ietf.org/archive/id/draft-ietf-taps-interface-13.html#section-9.1.3.4
	SafelyReplayable bool

	// Final, if true, this indicates a Message is the last that
	// the application will send on a Connection. This allows
	// underlying protocols to indicate to the Remote Endpoint
	// that the Connection has been effectively closed in the
	// sending direction. For example, TCP-based Connections can
	// send a FIN once a Message marked as Final has been
	// completely sent, indicated by marking
	// endOfMessage. Protocols that do not support signalling the
	// end of a Connection in a given direction will ignore this
	// property.
	//
	// See https://www.ietf.org/archive/id/draft-ietf-taps-interface-13.html#section-9.1.3.5
	Final bool

	// MsgChecksumLen specifies the minimum length of the section
	// of a sent Message, starting from byte 0, that the
	// application requires to be delivered without corruption due
	// to lower layer errors. It is used to specify options for
	// simple integrity protection via checksums. A value of 0
	// means that no checksum needs to be calculated, and Full
	// Coverage means that the entire Message needs to be
	// protected by a checksum. Only Full Coverage is guaranteed,
	// any other requests are advisory, which may result in Full
	// Coverage being applied.
	//
	// See https://www.ietf.org/archive/id/draft-ietf-taps-interface-13.html#section-9.1.3.6
	MsgChecksumLen uint

	// MsgReliable, if true, specifies that a Message should be
	// sent in such a way that the transport protocol ensures all
	// data is received on the other side without
	// corruption. Changing the Reliable Data Transfer property on
	// Messages is only possible for Connections that were
	// established enabling the Selection Property Configure
	// Per-Message Reliability. When this is not the case,
	// changing msgReliable will generate an error.
	//
	// Deprecated: The TAPS spec sets the default of this value to
	// "the queried Boolean value of the Selection Property
	// reliability", but the latter is never actually in
	// scope/queriable when the MessageContext object is
	// created. Not setting the parameter defaults to "false",
	// which is indistinguishable from actively setting it to
	// "false". Feedback welcome.
	//
	// See https://www.ietf.org/archive/id/draft-ietf-taps-interface-13.html#section-9.1.3.7
	MsgReliable bool

	// MsgCapacityProfile specifies the application's preferred
	// tradeoffs for sending this Message; it is a per-Message
	// override of the CapacityProfile ConnectionProperty
	//
	// Implementation note: The TAPS spec sets the default of this
	// value to "inherited from the Connection Property
	// connCapacityProfile", but the latter is never actually in
	// scope/queriable when the MessageContext object is
	// created. However, the default "Default" CapacityProfile is
	// defined as "no information about the expected capacity
	// profile", which this implementation interprets as "no
	// override" for the purposes of MessageContext. Feedback
	// welcome.
	//
	// See https://www.ietf.org/archive/id/draft-ietf-taps-interface-13.html#section-9.1.3.8
	MsgCapacityProfile enum.CapacityProfile

	// NoFragmentation specifies that a message should be sent and
	// received without network-layer fragmentation, if
	// possible. It can be used to avoid network layer
	// fragmentation when transport segmentation is prefered.
	//
	// This only takes effect when the transport uses a network
	// layer that supports this functionality. When it does take
	// effect, setting this property to true will cause the sender
	// to avoid network-layer source frgementation. When using
	// IPv4, this will result in the Don't Fragment bit being set
	// in the IP header.
	//
	// See https://www.ietf.org/archive/id/draft-ietf-taps-interface-13.html#section-9.1.3.9
	NoFragmentation bool

	// NoSegmentation, if set, requests the transport layer to not
	// provide segmentation of messages larger than the maximum
	// size permitted by the network layer, and also to avoid
	// network-layer source fragmentation of messages. When
	// running over IPv4, setting this property to true can result
	// in a sending endpoint setting the Don't Fragment bit in the
	// IPv4 header of packets generated by the transport layer. An
	// attempt to send a message that results in a size greater
	// than the transport's current estimate of its maximum packet
	// size (singularTransmissionMsgMaxLen) will result in a
	// SendError. This only takes effect when the transport and
	// network layer support this functionality.
	//
	// See https://www.ietf.org/archive/id/draft-ietf-taps-interface-13.html#section-9.1.3.10
	NoSegmentation bool
	// contains filtered or unexported fields
}

type Preconnection struct {
	LocalEndpoints      []*LocalEndpoint
	RemoteEndpoints     []*RemoteEndpoint
	TransportProperties *TransportProperties
	SecurityParameters  *SecurityParameters
}

type Protocol interface {
	Dial(Endpoint) (io.ReadWriteCloser, error)
	Accept(Endpoint) (io.ReadWriteCloser, error)
}

type RemoteEndpoint struct{ Endpoint }

type SecurityParameters struct {
	// Local identity and private keys: Used to perform private
	// key operations and prove one's identity to the Remote
	// Endpoint.
	Identity string
	KeyPair  KeyPair

	// Supported algorithms: Used to restrict what parameters are
	// used by underlying transport security protocols. When not
	// specified, these algorithms should use known and safe
	// defaults for the system. Parameters include: ciphersuites,
	// supported groups, and signature algorithms. These
	// parameters take a collection of supported algorithms as
	// parameter.
	SupportedGroup        tls.CurveID
	CipherSuite           *tls.CipherSuite
	SignatureAlgorithm    tls.SignatureScheme
	MaxCachedSessions     uint
	CachedSessionLifetime time.Duration

	// Unsupported
	PSK crypto.PrivateKey
}

type Service interface {
	GetPort() int //uint16?

}

type TransportProperties struct {
	// Reliability pecifies whether the application needs to use a
	// transport protocol that ensures that all data is received
	// at the Remote Endpoint without corruption. When reliable
	// data transfer is enabled, this also entails being notified
	// when a Connection is closed or aborted. (See
	// https://www.ietf.org/archive/id/draft-ietf-taps-interface-13.html#section-6.2.1)
	Reliability enum.Preference

	// PreserveMsgBoundaries specifies whether the application
	// needs or prefers to use a transport protocol that preserves
	// message boundaries. (See
	// https://www.ietf.org/archive/id/draft-ietf-taps-interface-13.html#section-6.2.2)
	PreserveMsgBoundaries enum.Preference

	// PerMsgReliability specifies whether an application
	// considers it useful to specify different reliability
	// requirements for individual Messages in a Connection. (See
	// https://www.ietf.org/archive/id/draft-ietf-taps-interface-13.html#section-6.2.3)
	PerMsgReliability enum.Preference

	// PreserveOrder specifies whether the application wishes to
	// use a transport protocol that can ensure that data is
	// received by the application on the other end in the same
	// order as it was sent. (See
	// https://www.ietf.org/archive/id/draft-ietf-taps-interface-13.html#section-6.2.4)
	PreserveOrder enum.Preference

	// ZeroRTTMsg specifies whether an application would like to
	// supply a Message to the transport protocol before
	// Connection establishment that will then be reliably
	// transferred to the other side before or 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
	// https://www.ietf.org/archive/id/draft-ietf-taps-interface-13.html#section-6.2.5)
	ZeroRTTMsg enum.Preference

	// Multistreaming specifies that the application would prefer
	// multiple Connections within a Connection Group to be
	// provided by streams of a single underlying transport
	// connection where possible.  (See
	// https://www.ietf.org/archive/id/draft-ietf-taps-interface-13.html#section-6.2.6)
	Multistreaming enum.Preference

	// FullChecksumSend specifies the application's need for
	// protection against corruption for all data transmitted on
	// this Connection. Disabling this property could enable later
	// control of the sender checksum coverage. (See
	// https://www.ietf.org/archive/id/draft-ietf-taps-interface-13.html#section-6.2.7)
	FullChecksumSend enum.Preference

	// FullChecksumRecv specifies the application's need for
	// protection against corruption for all data received on this
	// Connection. Disabling this property could enable later
	// control of the required minimum receiver checksum
	// coverage. (See
	// https://www.ietf.org/archive/id/draft-ietf-taps-interface-13.html#section-6.2.8)
	FullChecksumRecv enum.Preference

	// CongestionControl specifies whether the application would like
	// the Connection to be congestion controlled or not. Note
	// that if a Connection is not congestion controlled, an
	// application using such a Connection SHOULD itself perform
	// congestion control in accordance with [RFC2914] or use a
	// circuit breaker in accordance with [RFC8084], whichever is
	// appropriate. Also note that reliability is usually combined
	// with congestion control in protocol implementations,
	// rendering "reliable but not congestion controlled" a
	// request that is unlikely to succeed. If the Connection is
	// congestion controlled, performing additional congestion
	// control in the application can have negative performance
	// implications. (See
	// https://www.ietf.org/archive/id/draft-ietf-taps-interface-13.html#section-6.2.9)
	CongestionControl enum.Preference

	// KeepAlive specifies whether the application would like the
	// Connection to send keep-alive packets or not. Note that if
	// a Connection determines that keep-alive packets are being
	// sent, the applicaton should itself avoid generating
	// additional keep alive messages. Note that when supported,
	// the system will use the default period for generation of
	// the keep alive-packets. (See
	// https://www.ietf.org/archive/id/draft-ietf-taps-interface-13.html#section-6.2.10)
	KeepAlive enum.Preference

	// Interface allows the application to select any specific
	// network interfaces or categories of interfaces it wants to
	// Require, Prohibit, Prefer, or Avoid. Note that marking a
	// specific interface as Require strictly limits path
	// selection to that single interface, and often leads to less
	// flexible and resilient connection establishment. (See
	// https://www.ietf.org/archive/id/draft-ietf-taps-interface-13.html#section-6.2.11)
	//
	// Implementation Detail: In contrast to other Selection
	// Properties, this property maps interface identifier strings
	// to Preferences. In future, common interface types might
	// exist as constants.
	Interface map[string]enum.Preference

	// PvD allows the application to control path selection by
	// selecting which specific Provisioning Domain (PvD) or
	// categories of PVDs it wants to Require, Prohibit, Prefer,
	// or Avoid. Provisioning Domains define consistent sets of
	// network properties that may be more specific than network
	// interfaces [RFC7556]. (See
	// https://www.ietf.org/archive/id/draft-ietf-taps-interface-13.html#section-6.2.12)
	//
	// Implementation Detail: In contrast to other Selection
	// Properties, this property maps PvD identifier strings to
	// Preferences. In future, common PvD types and categories
	// might exist as constants.
	PvD map[string]enum.Preference

	// Multipath specifies whether and how applications want to
	// take advantage of transferring data across multiple paths
	// between the same end hosts. Using multiple paths allows
	// connections to migrate between interfaces or aggregate
	// bandwidth as availability and performance properties
	// change.
	//
	// The policy for using multiple paths is specified using the
	// separate MultipathPolicy ConnectionProperty. (See
	// https://www.ietf.org/archive/id/draft-ietf-taps-interface-13.html#section-6.2.14)
	Multipath enum.MultipathPreference

	// UseTemporaryLocalAddress allows the application to express
	// a preference for the use of temporary local addresses,
	// sometimes called "privacy" addresses [RFC4941]. Temporary
	// addresses are generally used to prevent linking connections
	// over time when a stable address, sometimes called
	// "permanent" address, is not needed. There are some caveats
	// to note when specifying this property. First, if an
	// application Requires the use of temporary addresses, the
	// resulting Connection cannot use IPv4, because temporary
	// addresses do not exist in IPv4. Second, temporary local
	// addresses might involve trading off privacy for
	// performance. For instance, temporary addresses can
	// interfere with resumption mechanisms that some protocols
	// rely on to reduce initial latency. (See
	// https://www.ietf.org/archive/id/draft-ietf-taps-interface-13.html#section-6.2.13)
	UseTemporaryLocalAddress enum.Preference

	// AdvertisesAltAddr specifies whether alternative addresses,
	// e.g., of other interfaces, should be advertised to the peer
	// endpoint by the protocol stack. Advertising these addresses
	// enables the peer-endpoint to establish additional
	// connectivity, e.g., for connection migration or using
	// multiple paths. (See
	// https://www.ietf.org/archive/id/draft-ietf-taps-interface-13.html#section-6.2.15)
	AdvertisesAltAddr bool

	// Direction specifies whether an application wants to use the connection for sending and/or receiving data.
	//
	// Since unidirectional communication can be supported by
	// transports offering bidirectional communication, specifying
	// unidirectional communication may cause a transport stack
	// that supports bidirectional communication to be
	// selected. (See
	// https://www.ietf.org/archive/id/draft-ietf-taps-interface-13.html#section-6.2.16)
	Direction enum.Directionality

	// SoftErrorNotify specifies whether an application considers
	// it useful to be informed when an ICMP error message arrives
	// that does not force termination of a connection. When set
	// to true, received ICMP errors are available as
	// SoftErrors. Note that even if a protocol supporting this
	// property is selected, not all ICMP errors will necessarily
	// be delivered, so applications cannot rely upon receiving
	// them [RFC8085]. (See
	// https://www.ietf.org/archive/id/draft-ietf-taps-interface-13.html#section-6.2.17)
	SoftErrorNotify enum.Preference

	// ActiveReadBeforeSend specifies whether an application wants
	// to diverge from the most common communication pattern - the
	// client actively opening a connection, then sending data to
	// the server, with the server listening (passive open),
	// reading and then answering. ActiveReadBeforeSend departs
	// from this pattern, either by actively opening with
	// Initiate(), immediately followed by reading, or passively
	// opening with Listen(), immediately followed by
	// writing. This property is ignored when establishing
	// connections using Rendezvous(). Requiring this property
	// limits the choice of mappings to underlying protocols,
	// which can reduce efficiency. For example, it prevents the
	// Transport Services system from mapping Connections to SCTP
	// streams, where the first transmitted data takes the role of
	// an active open signal. (See
	// https://www.ietf.org/archive/id/draft-ietf-taps-interface-13.html#section-6.2.18)
	ActiveReadBeforeSend enum.Preference
}