Replace connection_refused() with error_received().
This commit is contained in:
parent
d7061c0d55
commit
bf9b4e10d1
25
pep-3156.txt
25
pep-3156.txt
|
@ -1259,15 +1259,11 @@ Datagram transports have these methods:
|
||||||
|
|
||||||
Datagram transports call the following methods on the associated
|
Datagram transports call the following methods on the associated
|
||||||
protocol object: ``connection_made()``, ``connection_lost()``,
|
protocol object: ``connection_made()``, ``connection_lost()``,
|
||||||
``connection_refused()`` and ``datagram_received()``. ("Connection"
|
``error_received()`` and ``datagram_received()``. ("Connection"
|
||||||
in these method names is a slight misnomer, but the concepts still
|
in these method names is a slight misnomer, but the concepts still
|
||||||
exist: ``connection_made()`` means the transport representing the
|
exist: ``connection_made()`` means the transport representing the
|
||||||
endpoint has been created, and ``connection_lost()`` means the
|
endpoint has been created, and ``connection_lost()`` means the
|
||||||
transport is closed. The ``connection_refused()`` method is called
|
transport is closed.)
|
||||||
before ``connection_lost()`` when ``remote_addr`` was given and an
|
|
||||||
explicit negative acknowledgement was received (this is a UDP
|
|
||||||
feature). (TBD: Should fix `connection_refused()`` to not close the
|
|
||||||
transport.)
|
|
||||||
|
|
||||||
Subprocess Transports
|
Subprocess Transports
|
||||||
'''''''''''''''''''''
|
'''''''''''''''''''''
|
||||||
|
@ -1390,20 +1386,17 @@ In addition, they have the following methods:
|
||||||
``data`` (a bytes objects) was received from remote address ``addr``
|
``data`` (a bytes objects) was received from remote address ``addr``
|
||||||
(an IPv4 2-tuple or an IPv6 4-tuple).
|
(an IPv4 2-tuple or an IPv6 4-tuple).
|
||||||
|
|
||||||
- ``connection_refused(exc)``. Indicates that a send or receive
|
- ``error_received(exc)``. Indicates that a send or receive operation
|
||||||
operation raised a ``ConnectionRefused`` exception. This typically
|
raised an ``OSError`` exception. Since datagram errors may be
|
||||||
indicates that a negative acknowledgment was received for a
|
transient, it is up to the protocol to call the transport's
|
||||||
previously sent datagram (not for the datagram that was being sent,
|
``close()`` method if it wants to close the endpoint.
|
||||||
if the exception was raised by a send operation). Immediately after
|
|
||||||
this the socket will be closed and ``connection_lost()`` will be
|
|
||||||
called with the same exception argument.
|
|
||||||
|
|
||||||
Here is a chart indicating the order and multiplicity of calls:
|
Here is a chart indicating the order and multiplicity of calls:
|
||||||
|
|
||||||
1. ``connection_made()`` -- exactly once
|
1. ``connection_made()`` -- exactly once
|
||||||
2. ``datagram_received()`` -- zero or more times
|
2. ``datagram_received()``, ``error_received()`` -- zero or more times
|
||||||
3. ``connection_refused()`` -- at most once
|
3. ``connection_lost()`` -- exactly once
|
||||||
4. ``connection_lost()`` -- exactly once
|
|
||||||
|
|
||||||
Subprocess Protocol
|
Subprocess Protocol
|
||||||
'''''''''''''''''''
|
'''''''''''''''''''
|
||||||
|
|
Loading…
Reference in New Issue