> On Nov 25, 2015, at 04:54, Oon-Ee Ng <ngoonee.t...@gmail.com> wrote:
>
> On Tue, Nov 24, 2015 at 11:03 AM, Oon-Ee Ng <ngoonee.t...@gmail.com> wrote:
>> And furthermore that when I do that, callRemote no longer returns a
>> deferred (which makes sense, really) and instead gets a None. One more
>> check before I add my default errBacks then. Optimised network traffic
>> sounds positive, at the least (I assume this means one less
>> transmission since it effectively makes the AMP one-way for the
>> messages which have this set to False).
>
> Just realized, requiresAnswer=False means I can't add errBacks, which
> means there's no way to handle a receiver-side error. Is this correct?
That is correct. But you shouldn't want to handle errors there :-). Don't
think of a requiresAnswer=False command as an optimization; instead, think of
it as a piece of information being relayed.
For example; consider an HTTP stream. The client sends a request. If the
server has an error, it sends an error code. Then, the server sends the
entity-body, one chunk at a time.
The client has to process each of those chunks one after another. If the
server sends a chunk and the client encounters an error, there's nothing for
the server to do; the client has no way to communicate it and it can just
disconnect. You would use requiresAnswer=False (as you are already doing in
your case) to send a chunk of data like those entity-body chunks, which ought
not to be a message that... requires an answer. It's just a way of encoding
some data on the connection.
Make sense?
-glyph
_______________________________________________
Twisted-Python mailing list
Twisted-Python@twistedmatrix.com
http://twistedmatrix.com/cgi-bin/mailman/listinfo/twisted-python
