[Twisted-Python] order of remote requests

Brian Warner warner at lothar.com
Wed Dec 30 18:07:43 EST 2009

Andrew Bennetts wrote:

> So it is impossible for the internet to route the messages such that B
> will arrive before A.
> Neither PB nor TCP guarantee anything about when the recipient
> “processes” those messages though, just that they will arrive in the
> order they were sent.  For example consider if A and B arrive very close
> together (in the same millisecond, say) and the client processes them by
> dispatching to a thread pool,

To expand on what Andrew said: Foolscap (which is descended from PB and
has very similar semantics) makes the following guarantee:

 within any given client/server pair,
 if the client invokes callRemote(A) before invoking callRemote(B)
 then the server will invoke remote_A() before invoking remote_B()

Your server's remote_A() method might return a Deferred, and not fire it
for an arbitrary period of time, whereas it might return an immediate
value from remote_B(). In this case, the client will see the responses
come back in a different order. Your server might also choose to delay
processing of one message for whatever reason (like by dispatching to a
threadpool, or dispatching a request to a third server in order to
service the request), but will be visible in the implementation of
remote_A(). The only promise made by Foolscap and PB is that your
remote_* methods will be invoked in the same order as the sender called

(in the future, Foolscap might offer some options to use multiple
connections and send messages over multiple parallel paths, or to
interleave message calls on a single connection, or to switch to UDP or
something, which might weaken this guarantee, but the default will
remain FIFO ordering)

Also note that there are no ordering guarantees between messages sent to
different machines (and therefore over different connections), of course.


Foolscap: http://foolscap.lothar.com/trac

More information about the Twisted-Python mailing list