andrew at bemusement.org
Wed Mar 24 18:22:03 EDT 2010
Albert Brandl wrote:
> The NetstringReceiver class does not exactly do what I'd expect - see
> issue http://twistedmatrix.com/trac/ticket/4378. Since we plan to use
> netstrings, I am trying to fix it.
> I am not quite sure how to handle certain problems, though, and that's
> where I'd appreciate help. If this is the wrong place to ask this kind of
> questions, please redirect me ;-).
> 1.) In the current implementation, a NetstringParseError results in a
> call to self.transport.loseConnection(). Furthermore the variable
> brokenPeer is set to 1. But this variable is ignored. Would it be better
> to check it before receiving data? If yes: what is the correct way for a
> protocol to handle a broken transport? There is a ConnectionLost
> exception, but I'm not sure if / when a Protocol is allowed to raise it.
No; I think once loseConnection has been called dataReceived won't be
called again, so there's no point checking for brokenPeer in
It might be worth checking in sendString, but I would expect that it
would already raise an appropriate exception because it will try to
write to a closed transport.
> 2.) The current implementation uses the method dataReceived to assemble
> the content of the netstring. When it is complete, the method
> stringReceived (which raises a NotImplementedError by default) is called.
> But netstrings can be long - would it be better to create a Deferred
> instance and call its callback instead? What would be the right place to
> create this Deferred?
I'm rather confused about why you're even asking this question. Exactly
what API are you proposing as an alternative to the existing API (which
is subclass NetstringReceiver and override stringReceived, and
stringReceived will be called for every netstring that is received, as
soon as it is received)?
> 3.) I started testing the NetstringReceiver by creating a class comment
> with doctests. When I later grepped the sources, I found some doctests,
> but there no mention of the doctest module in the test policy document.
> Would it be better to use the unittest framework for testing the code?
There are some existing tests for NetstringReceiver in
More information about the Twisted-Python