<br><br><br><div class="gmail_quote">On Wed, Aug 5, 2009 at 12:14 AM, Johann Borck <span dir="ltr"><<a href="mailto:johann.borck@densedata.com">johann.borck@densedata.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
<div class="im"><br>
On Tue, Aug 4, 2009 at 10:08 AM, John Aherne <<a href="mailto:johnaherne@rocs.co.uk">johnaherne@rocs.co.uk</a><br>
</div><div class="im"><mailto:<a href="mailto:johnaherne@rocs.co.uk">johnaherne@rocs.co.uk</a>>> wrote:<br>
> This is a really basic problem we are trying to decide about,<br>
><br>
> We have programs that run quite happily, so far. Its main task is to<br>
> receive data from port A and send it out via port B. Then receive data<br>
> via port B and send it out via port A. It's pretty much like a chat<br>
> setup. You just build up a list of connected clients and send data to<br>
> them as required<br>
><br>
> One side A receives some input from a tcp port - about 100-200<br>
> characters, and forwards it to another port B. We do not need to wait<br>
> for any response. If we get a response we pick that up through line<br>
> receiver. We also run a calllater to check if we got a response on<br>
> linereceiver within the timeframe specified. If not we drop the<br>
> connection.<br>
><br>
> Traffic coming in from port B is analysed and some subset is sent back<br>
> to port A.<br>
><br>
> Ignoring port A for the moment, just concentrating on port B, we have<br>
> tried three options:--<br>
><br>
> 1. We set up a defer to handle the sendline to port B so that the<br>
> reactor would schedule it in its own good time.<br>
<br>
</div>The reactor always schedules reads and writes "in its own good time",<br>
which means it writes whenever there's data to write and the socket is<br>
ready for writing. If you have data that can't be written at once,<br>
because it's too much for the socket to handle in a non-blocking<br>
fashion, the reactor (along with the transport) will take care of it,<br>
and defer its delivery itself, no need for any deferreds you'd had to<br>
care about here.<br>
<br>
Correct me if I'm wrong, but as I understand your description, option 1.<br>
and 2. do not behave identically. This is how I interpret it:<br>
option 1:<br>
<br>
A sends msg1 to [svc] : wrap msg1 in deferred1<br>
[ - time - ]<br>
B sends data? to [svc] :<br>
1. callback deferred1: [svc]<br>
sends msg1 to B<br>
2. handle data?<br>
B sends rsp1 to [svc]: [svc] sends rsp1 to A<br>
<br>
option 2:<br>
<br>
A sends msg1 to [svc] : [svc] sends msg1 to B<br>
B sends rsp1 to [svc] : [svc] sends rsp1 to A<br>
<br>
If this is the case, you rely on some data? being sent to [svc] before<br>
msg1 can be forwarded to B. That means that you have msg1 in memory<br>
until you receive data? from B. This doesn't cause problems in your<br>
case, since you handle small messages in big intervals. But if you'd<br>
increase the load significantly, you'd also need significantly more RAM<br>
for no good reason. A case where option 1 might make sense would be if<br>
it depended on data? provided by B, to decide if or how to continue<br>
processing msg1. Then you had a valid use-case for deferreds. Since<br>
there are no such requirements, option 2 is definitely the right choice.<br>
<div class="im"><br>
> No threads involved using the standard twisted setup. When we get a<br>
> response through receiveline we fire the callback defer. If we timeout<br>
> via callLater we fire the errback to clear the defer. In this case the<br>
> defer does not seem to be doing very much<br>
><br>
> 2. Now a fresh pair of eyes is looking at the code and saying why are<br>
> we using a deferred for sending data to port B. We could just issue a<br>
> straight sendline as part of the main code and carry on. If we get a<br>
> response via linereceiver,we process it normally, otherwise we set our<br>
> callLater running and timeout and lose the connection. So no deferreds<br>
> required at all. It does seem to work.What we are not sure about is<br>
> what penalty is incurred in terms of reliability or throughput by<br>
> using sendline without a deferred.<br>
<br>
</div>There's absolutely no penalty (unless you allow the notion of negative<br>
penalties). Using sendline directly is faster than using a deferred in<br>
between, even if you don't count the memory overhead. I think there's a<br>
bit confusion about the role of deferreds in twisted here. Deferreds<br>
don't help you (or the reactor) with scheduling, they only provide you<br>
with a means to continue some processing after a certain event occurred.<br>
<div class="im">> We are not too sure what the holdup will be and whether it could end<br>
> up halting the show. Is it better to schedule these messages via<br>
> deferreds or am I missing something obvious<br>
><br>
> 3. So we then did an experiment and used defertothread to run the<br>
> sendline in a separate thread with its own defer to maximise the<br>
> asynchronous running of the code. So now we are running threads when<br>
> one of the reasons for looking at twisted was that we could avoid<br>
> threads as much as possible.<br>
<br>
</div>Do you use sendline (the twisted api) from within the thread? If yes<br>
and it works, it works accidentally, probably also due to the very small<br>
load, and is definitely wrong (as well as unnecessary), twisted is not<br>
threadsafe, with the exception of a few methods/functions like<br>
callInThread/callFromThread/defertoThread etc.<br>
<br>
<br>
hope that helps,<br>
<font color="#888888">Johann<br>
</font><div><div></div><div class="h5"><br>
_______________________________________________<br>
Twisted-Python mailing list<br>
<a href="mailto:Twisted-Python@twistedmatrix.com">Twisted-Python@twistedmatrix.com</a><br>
<a href="http://twistedmatrix.com/cgi-bin/mailman/listinfo/twisted-python" target="_blank">http://twistedmatrix.com/cgi-bin/mailman/listinfo/twisted-python</a><br>
</div></div></blockquote></div><br><br>Johann<br>
<br>
Thanks for a very informative reply.<br>
<br>
Our problem was more basic than deferreds. It was to with the reactor and select command.<br>
<br>Sendline is not blocking so as you say we can avoid the use of deferreds and continue to use sendline directly.<br>
<br>Regarding messages being stored in memory, we only store the sequence number for each message so we can identify the message being responded to. We can then report back to A with the original message sequence number. So the memory footprint is quite small.<br>
<br>Our option 3 using defertothread does use sendline from the thread. Your response implies that is OK since you say defertothread is threadsafe. Did you really mean that.<br><br>Once again thanks for a very good response. That has cleared up a lot of confusion.<br>
<br>I suppose it would help if there was a paragraph at the start of the twisted documentation detailing what you have just said. So when they start on deferreds you have some sort of context in which to interpret what is being said<br>
<br>Regards<br><br>John Aherne<br><br><br>