tolerate data arriving briefly after we hang up
If the file receiver hangs up on an established connection, we do a `transport.loseConnection()` on the buddy (the file sender). But apparently it takes a moment (perhaps a roundtrip through the kernel) for the incoming data to stop, and that used to cause an error. In May 2020 this happened 11 times in 40 days. Now we just ignore this late data.
This commit is contained in:
parent
851b7474d8
commit
1242f36624
|
@ -56,6 +56,14 @@ class TransitConnection(protocol.Protocol):
|
||||||
# practice, this buffers about 10MB per connection, after which
|
# practice, this buffers about 10MB per connection, after which
|
||||||
# point the sender will only transmit data as fast as the
|
# point the sender will only transmit data as fast as the
|
||||||
# receiver can handle it.
|
# receiver can handle it.
|
||||||
|
if not self._buddy:
|
||||||
|
# Our buddy disconnected (we're "jilted"), so we hung up too,
|
||||||
|
# but our incoming data hasn't stopped yet (it will in a
|
||||||
|
# moment, after our disconnect makes a roundtrip through the
|
||||||
|
# kernel). This probably means the file receiver hung up, and
|
||||||
|
# this connection is the file sender. In may-2020 this
|
||||||
|
# happened 11 times in 40 days.
|
||||||
|
return
|
||||||
self._total_sent += len(data)
|
self._total_sent += len(data)
|
||||||
self._buddy.transport.write(data)
|
self._buddy.transport.write(data)
|
||||||
return
|
return
|
||||||
|
|
Loading…
Reference in New Issue
Block a user