[Twisted-Python] ITransport.write after IProtocol.connectionLost -- no failure/exception?

[Cory Benfield]

> On 15 Dec 2016, at 12:07, exvito here <ex.vitorino at gmail.com> wrote:
> 
> Dear all,
> 
> The subject says most of it. While diagnosing a behavior on a somewhat
> large codebase, I found out something somewhat surprising -- see
> subject -- which is replicated with the minimal code example below.
> 
> It is a LineReceiver client that:
> 1. Connects to 127.0.0.1:10000.
> 2. Sends a line of text.
> 3. Disconnects one second later.
> 4. Tries to send another line of text, one second after disconnection.
> 
> I expected step 4 to fail somehow, given that Twisted promptly
> detected that the connection closed and IProtocol.connectionLost was
> called, as documented. Nevertheless, it does not fail.

I can’t speak for the design of Twisted, but this is definitely an intended implementation behaviour: because twisted’s write method is non-blocking, it is generally nicer to avoid write exploding in your face when disconnected.

> b) Does a protocol implementation, like the one in the example, really
> need to track connectionMade / connectionLost calls before going for
> self.transport.write?

A well-written protocol should stop finding reasons to write once connectionLost is called, yes. Similarly, it should probably avoid writing before connectionMade.

> c) Can a protocol implementation, instead, depend on
> self.transport.connected for which I found no documentation? (I
> probably missed it, where is it?)

I have no good answer to this one, but basically I suspect the answer is “yes, for the default TCP transports”, but “no, not in the general case, because it’s not part of a documented interface”.

Cory