draft-trammell-taps-post-sockets-02.txt | draft-trammell-taps-post-sockets-03.txt | |||
---|---|---|---|---|
skipping to change at page 1, line 16 ¶ | skipping to change at page 1, line 16 ¶ | |||
Expires: April 30, 2018 University of Glasgow | Expires: April 30, 2018 University of Glasgow | |||
T. Pauly | T. Pauly | |||
Apple Inc. | Apple Inc. | |||
M. Kuehlewind | M. Kuehlewind | |||
ETH Zurich | ETH Zurich | |||
C. Wood | C. Wood | |||
Apple Inc. | Apple Inc. | |||
October 27, 2017 | October 27, 2017 | |||
Post Sockets, An Abstract Programming Interface for the Transport Layer | Post Sockets, An Abstract Programming Interface for the Transport Layer | |||
draft-trammell-taps-post-sockets-02 | draft-trammell-taps-post-sockets-03 | |||
Abstract | Abstract | |||
This document describes Post Sockets, an asynchronous abstract | This document describes Post Sockets, an asynchronous abstract | |||
programming interface for the atomic transmission of messages in an | programming interface for the atomic transmission of messages in an | |||
inherently multipath environment. Post replaces connections with | inherently multipath environment. Post replaces connections with | |||
long-lived associations between endpoints, with the possibility to | long-lived associations between endpoints, with the possibility to | |||
cache cryptographic state in order to reduce amortized connection | cache cryptographic state in order to reduce amortized connection | |||
latency. We present this abstract interface as an illustration of | latency. We present this abstract interface as an illustration of | |||
what is possible with present developments in transport protocols | what is possible with present developments in transport protocols | |||
skipping to change at page 2, line 41 ¶ | skipping to change at page 2, line 41 ¶ | |||
2.8. Path . . . . . . . . . . . . . . . . . . . . . . . . . . 14 | 2.8. Path . . . . . . . . . . . . . . . . . . . . . . . . . . 14 | |||
3. Abstract Programming Interface . . . . . . . . . . . . . . . 15 | 3. Abstract Programming Interface . . . . . . . . . . . . . . . 15 | |||
3.1. Example Connection Patterns . . . . . . . . . . . . . . . 16 | 3.1. Example Connection Patterns . . . . . . . . . . . . . . . 16 | |||
3.1.1. Client-Server . . . . . . . . . . . . . . . . . . . . 16 | 3.1.1. Client-Server . . . . . . . . . . . . . . . . . . . . 16 | |||
3.1.2. Client-Server with Happy Eyeballs and 0-RTT | 3.1.2. Client-Server with Happy Eyeballs and 0-RTT | |||
establishment . . . . . . . . . . . . . . . . . . . . 18 | establishment . . . . . . . . . . . . . . . . . . . . 18 | |||
3.1.3. Peer to Peer with Network Address Translation . . . . 18 | 3.1.3. Peer to Peer with Network Address Translation . . . . 18 | |||
3.1.4. Multicast Receiver . . . . . . . . . . . . . . . . . 18 | 3.1.4. Multicast Receiver . . . . . . . . . . . . . . . . . 18 | |||
3.1.5. Association Bootstrapping . . . . . . . . . . . . . . 19 | 3.1.5. Association Bootstrapping . . . . . . . . . . . . . . 19 | |||
3.2. API Dynamics . . . . . . . . . . . . . . . . . . . . . . 20 | 3.2. API Dynamics . . . . . . . . . . . . . . . . . . . . . . 20 | |||
4. Implementation Considerations . . . . . . . . . . . . . . . . 23 | 4. Implementation Considerations . . . . . . . . . . . . . . . . 22 | |||
4.1. Protocol Stack Instance (PSI) . . . . . . . . . . . . . . 23 | 4.1. Protocol Stack Instance (PSI) . . . . . . . . . . . . . . 23 | |||
4.2. Message Framing, Parsing, and Serialization . . . . . . . 24 | 4.2. Message Framing, Parsing, and Serialization . . . . . . . 24 | |||
4.3. Message Size Limitations . . . . . . . . . . . . . . . . 25 | 4.3. Message Size Limitations . . . . . . . . . . . . . . . . 25 | |||
4.4. Back-pressure . . . . . . . . . . . . . . . . . . . . . . 26 | 4.4. Back-pressure . . . . . . . . . . . . . . . . . . . . . . 25 | |||
4.5. Associations, Transients, Racing, and Rendezvous . . . . 26 | 4.5. Associations, Transients, Racing, and Rendezvous . . . . 26 | |||
5. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 28 | 5. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 28 | |||
6. References . . . . . . . . . . . . . . . . . . . . . . . . . 28 | 6. References . . . . . . . . . . . . . . . . . . . . . . . . . 28 | |||
6.1. Normative References . . . . . . . . . . . . . . . . . . 28 | 6.1. Normative References . . . . . . . . . . . . . . . . . . 28 | |||
6.2. Informative References . . . . . . . . . . . . . . . . . 29 | 6.2. Informative References . . . . . . . . . . . . . . . . . 28 | |||
Appendix A. Open Issues . . . . . . . . . . . . . . . . . . . . 30 | Appendix A. Open Issues . . . . . . . . . . . . . . . . . . . . 30 | |||
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 31 | Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 30 | |||
1. Introduction | 1. Introduction | |||
The BSD Unix Sockets API's SOCK_STREAM abstraction, by bringing | The BSD Unix Sockets API's SOCK_STREAM abstraction, by bringing | |||
network sockets into the UNIX programming model, allowing anyone who | network sockets into the UNIX programming model, allowing anyone who | |||
knew how to write programs that dealt with sequential-access files to | knew how to write programs that dealt with sequential-access files to | |||
also write network applications, was a revolution in simplicity. It | also write network applications, was a revolution in simplicity. It | |||
would not be an overstatement to say that this simple API is the | would not be an overstatement to say that this simple API is the | |||
reason the Internet won the protocol wars of the 1980s. SOCK_STREAM | reason the Internet won the protocol wars of the 1980s. SOCK_STREAM | |||
is tied to the Transmission Control Protocol (TCP), specified in 1981 | is tied to the Transmission Control Protocol (TCP), specified in 1981 | |||
skipping to change at page 16, line 33 ¶ | skipping to change at page 16, line 33 ¶ | |||
highest probably for a successful connection attempt) or which PSIs | highest probably for a successful connection attempt) or which PSIs | |||
to probe for (first). A Transient is created when an application | to probe for (first). A Transient is created when an application | |||
actually sends a Message over a Carrier. As further explained below | actually sends a Message over a Carrier. As further explained below | |||
this step can actually create multiple transients for probing or | this step can actually create multiple transients for probing or | |||
assign a new transient to an already active PSI, e.g. if multi- | assign a new transient to an already active PSI, e.g. if multi- | |||
streaming is provided and supported for these kind of use on both | streaming is provided and supported for these kind of use on both | |||
sides. | sides. | |||
3.1. Example Connection Patterns | 3.1. Example Connection Patterns | |||
[EDITOR'S NOTE: ensure these are in line with the Section 3.2 below.] | ||||
Here, we illustrate the usage of the API for common connection | Here, we illustrate the usage of the API for common connection | |||
patterns. Note that error handling is ignored in these illustrations | patterns. Note that error handling is ignored in these illustrations | |||
for ease of reading. | for ease of reading. | |||
3.1.1. Client-Server | 3.1.1. Client-Server | |||
Here's an example client-server application. The server echoes | Here's an example client-server application. The server echoes | |||
messages. The client sends a message and prints what it receives. | messages. The client sends a message and prints what it receives. | |||
The client in Figure 2 connects, sends a message, and sets up a | The client in Figure 2 connects, sends a message, and sets up a | |||
skipping to change at page 22, line 21 ¶ | skipping to change at page 22, line 21 ¶ | |||
+--- .OnExpired() | +--- .OnExpired() | |||
+--- .OnClosed() | +--- .OnClosed() | |||
Figure 7: Sending and Receiving Messages and Events | Figure 7: Sending and Receiving Messages and Events | |||
An application may have a global Configuation, as well as more | An application may have a global Configuation, as well as more | |||
specific Configurations to apply to the establishment of a given | specific Configurations to apply to the establishment of a given | |||
Association or Carrier. These Configurations are optional arguments | Association or Carrier. These Configurations are optional arguments | |||
to the Association and Carrier creation calls. | to the Association and Carrier creation calls. | |||
[EDITOR'S NOTE (bht): the text below does not belong here, figure out | ||||
what to do with it when https://github.com/mami-project/draft- | ||||
trammell-post-sockets/pull/23 lands: Each Configuration is | ||||
conceptually a key-value store, where information in more specific | ||||
scopes overrides information in less specific scopes: application | ||||
defaults can be overriden by specific Configurations bound to | ||||
Carriers or Associations, all of which may be overriden by system or | ||||
user-scoped configuration parameters. Configurations are also made | ||||
directly available to protocol stack instances (PSIs, see | ||||
Section 4.1) for fine-grained control of implementation-specific | ||||
configuration parameters.] | ||||
In order to initiate a connection with a remote endpoint, a user of | In order to initiate a connection with a remote endpoint, a user of | |||
Post Sockets must start from a Remote (see Section 2.4). A Remote | Post Sockets must start from a Remote (see Section 2.4). A Remote | |||
encapsulates identifying information about a remote endpoint at a | encapsulates identifying information about a remote endpoint at a | |||
specific level of resolution. A new Remote can be wrapped around | specific level of resolution. A new Remote can be wrapped around | |||
some identifying information by via the NewRemote() call. A Remote | some identifying information by via the NewRemote() call. A Remote | |||
has a .Resolve() method, which can be iteratively revoked to increase | has a .Resolve() method, which can be iteratively revoked to increase | |||
the level of resolution; a call to Resolve on a given Remote may | the level of resolution; a call to Resolve on a given Remote may | |||
result in one to many Remotes, as shown in Figure 8. Remotes at any | result in one to many Remotes, as shown in Figure 8. Remotes at any | |||
level of resolution may be passed to Post Sockets calls; each call | level of resolution may be passed to Post Sockets calls; each call | |||
will continue resolution to the point necessary to establish or | will continue resolution to the point necessary to establish or | |||
End of changes. 7 change blocks. | ||||
19 lines changed or deleted | 5 lines changed or added | |||
This html diff was produced by rfcdiff 1.46. The latest version is available from http://tools.ietf.org/tools/rfcdiff/ |