Add high-level explanation of transports and protocols early on.
This commit is contained in:
parent
c49b0d1ebc
commit
6f0acba7b3
41
pep-3156.txt
41
pep-3156.txt
|
@ -76,6 +76,47 @@ interface; there is an API to submit a function to an executor (see
|
||||||
PEP 3148) which returns a Future that is compatible with the event
|
PEP 3148) which returns a Future that is compatible with the event
|
||||||
loop.
|
loop.
|
||||||
|
|
||||||
|
A Note About Transports and Protocols
|
||||||
|
-------------------------------------
|
||||||
|
|
||||||
|
For those not familiar with Twisted, a quick explanation of the
|
||||||
|
difference between transports and protocols is in order. At the
|
||||||
|
highest level, the transport is concerned with *how* bytes are
|
||||||
|
transmitted, while the protocol determines *which* bytes to transmit
|
||||||
|
(and when).
|
||||||
|
|
||||||
|
A transport represents a pair of streams (one in each direction) that
|
||||||
|
each transmit a sequence of bytes. The most common transport is
|
||||||
|
probably the TCP connection. Another common transport is SSL. But
|
||||||
|
there are some other things that can be viewed as transports, for
|
||||||
|
example an SSH session or a pair of UNIX pipes. Typically there
|
||||||
|
aren't many different transport implementations, and most of them
|
||||||
|
come with the event loop implementation.
|
||||||
|
|
||||||
|
A transport has two "sides": one side talks to the network (or the
|
||||||
|
subprocess, or whatever low-level interface it wraps), and the other
|
||||||
|
side talks to the protocol. The former uses whatever API is necessary
|
||||||
|
to implement the transport; but the interface between transport and
|
||||||
|
protocol is standardized by this PEP.
|
||||||
|
|
||||||
|
A protocol represents some kind of "application-level" protocol such
|
||||||
|
as HTTP or SMTP. Its primary interface is with the transport. While
|
||||||
|
some popular protocols will probably have a standard implementation,
|
||||||
|
often applications implement custom protocols. It also makes sense to
|
||||||
|
have libraries of useful 3rd party protocol implementations that can
|
||||||
|
be downloaded and installed from pypi.python.org.
|
||||||
|
|
||||||
|
There is also a somewhat more general notion of transport and
|
||||||
|
protocol, where the transport wraps some other communication
|
||||||
|
abstraction. Example include an interface for sending and receiving
|
||||||
|
datagrams, or a subprocess manager. The separation of concerns is the
|
||||||
|
same as for stream transports and protocols, but the specific
|
||||||
|
interface between transport and protocol can be different in each
|
||||||
|
case.
|
||||||
|
|
||||||
|
Details of the interfaces between transports and protocols are given
|
||||||
|
later.
|
||||||
|
|
||||||
|
|
||||||
Non-goals
|
Non-goals
|
||||||
=========
|
=========
|
||||||
|
|
Loading…
Reference in New Issue