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
|
||||
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
|
||||
=========
|
||||
|
|
Loading…
Reference in New Issue