[Twisted-Python] twisted TCP frame size

Jean-Paul Calderone exarkun at divmod.com
Mon Feb 27 12:44:36 EST 2006

On Mon, 27 Feb 2006 16:44:18 +0000, Phil Mayers <p.mayers at imperial.ac.uk> wrote:
>Thys Meintjes wrote:
>>1) is there a way to force dataReceived() to return when a certain data
>>length has been received ?
>dataReceived() is called via doRead() on the file descriptor, which is 
>called via a select([fd,], [], []) event in the default reactor.
>If you are doing something (executing code) and a TCP segment comes in, then 
>another, then another, *then* you exit your code and the reactor falls back 
>to select(), it'll return with the fd and doRead() will be called, and 
>you'll get everything from the socket - 3 frames worth.
>The correct question is, given your test script has a very small 
>dataReceived method that returns quickly (I presume), why isn't the reactor 
>"beating" the server and getting 49 bytes every time?

Of course, it isn't necessarily the case that multiple TCP packets, each with 49 bytes of application-level data, are arriving between the times doRead()/dataReceived() get invoked.  Nagling on the server could cause data to arrive in multiples of 49 bytes just as easily as a slow receiver.  This could happen with the synchronous version too, you just wouldn't be able to notice it.  What Twisted does in this case is actually more efficient, since it involves fewer trips into recv(), less memory copying, etc.

Of course all the other stuff Twisted does might outweigh this (and likely does - the overhead associated with synchronously reading from one socket is much lower than the overhead of performing the same task asynchronously, at least when using select()).  Which is not to say that the Twisted version has to be slower, but you might have to work harder to see any benefits at this (essentially non-existent) level of concurrency.


More information about the Twisted-Python mailing list