> On 15 Dec 2016, at 12:07, exvito here <ex.vitor...@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 _______________________________________________ Twisted-Python mailing list Twisted-Python@twistedmatrix.com http://twistedmatrix.com/cgi-bin/mailman/listinfo/twisted-python
