Re: [Twisted-Python] order of remote requests

2009-12-30 Thread Brian Warner
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
callRemote(*).

(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.


cheers,
 -Brian

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


___
Twisted-Python mailing list
Twisted-Python@twistedmatrix.com
http://twistedmatrix.com/cgi-bin/mailman/listinfo/twisted-python


Re: [Twisted-Python] order of remote requests

2009-12-29 Thread Andrew Bennetts
Wolfgang Rohdewald wrote:
 Hi,
 
 when I send two remote calls A and B over the network, in that
 order, using the twisted perspective broker callRemote method,
 is it granted that A is processed first on the other side even
 if B  arrives first? Or should I only send B after I got an
 answer to A?

It depends on the server, and what exactly you want to happen.

Perspective broker can have many concurrent remote calls on the same
connection, and depending on how the server is implemented it might
process those sequentially in the order they arrive, or concurrently, or
even in an arbitrary order.

So if call A really must be completed before starting B, then the client
must not make call B until it knows A has finished.

-Andrew.


___
Twisted-Python mailing list
Twisted-Python@twistedmatrix.com
http://twistedmatrix.com/cgi-bin/mailman/listinfo/twisted-python


Re: [Twisted-Python] order of remote requests

2009-12-29 Thread Wolfgang Rohdewald
On Tuesday 29 December 2009, Andrew Bennetts wrote:
 Wolfgang Rohdewald wrote:
  when I send two remote calls A and B over the network, in that
  order, using the twisted perspective broker callRemote method,
  is it granted that A is processed first on the other side even
  if B  arrives first? Or should I only send B after I got an
  answer to A?
 
 It depends on the server, and what exactly you want to happen.
 
 Perspective broker can have many concurrent remote calls on the
  same connection, and depending on how the server is implemented it
  might process those sequentially in the order they arrive, or
  concurrently, or even in an arbitrary order.
 
 So if call A really must be completed before starting B, then the
  client must not make call B until it knows A has finished.

I should have given more details, sorry.

I am writing both the server and the client with twisted pb.
The server (a game server) sends messages to four player clients.

Say the game server sends messages A and B to a player client. 

Is it granted that the player client always processes A first even
if the internet routes the messages differently and B arrives
first?

-- 
Wolfgang

___
Twisted-Python mailing list
Twisted-Python@twistedmatrix.com
http://twistedmatrix.com/cgi-bin/mailman/listinfo/twisted-python


Re: [Twisted-Python] order of remote requests

2009-12-29 Thread David Ripton
On 2009.12.29 12:53:07 +0100, Wolfgang Rohdewald wrote:
 On Tuesday 29 December 2009, Andrew Bennetts wrote:
  Wolfgang Rohdewald wrote:
   when I send two remote calls A and B over the network, in that
   order, using the twisted perspective broker callRemote method,
   is it granted that A is processed first on the other side even
   if B  arrives first? Or should I only send B after I got an
   answer to A?
  
  It depends on the server, and what exactly you want to happen.
  
  Perspective broker can have many concurrent remote calls on the
   same connection, and depending on how the server is implemented it
   might process those sequentially in the order they arrive, or
   concurrently, or even in an arbitrary order.
  
  So if call A really must be completed before starting B, then the
   client must not make call B until it knows A has finished.
 
 I should have given more details, sorry.
 
 I am writing both the server and the client with twisted pb.
 The server (a game server) sends messages to four player clients.
 
 Say the game server sends messages A and B to a player client. 
 
 Is it granted that the player client always processes A first even
 if the internet routes the messages differently and B arrives
 first?

TCP guarantees in-order message delivery.  If you send A before B over
the same TCP connection, and A and B reach the client, then the client
will receive A before B.

Each Twisted process is single-threaded by default.

So if you use TCP, and keep the message processing code simple, then I
think you'll get messages processed in the order you expect.  I've never
noticed a problem with out-of-order messages in my PB game, anyway.

-- 
David Riptondrip...@ripton.net

___
Twisted-Python mailing list
Twisted-Python@twistedmatrix.com
http://twistedmatrix.com/cgi-bin/mailman/listinfo/twisted-python


Re: [Twisted-Python] order of remote requests

2009-12-29 Thread Wolfgang Rohdewald
On Tuesday 29 December 2009, David Ripton wrote:
 TCP guarantees in-order message delivery.  If you send A before B
  over the same TCP connection, and A and B reach the client, then
  the client will receive A before B.

Of course - now I wonder what made me think otherwise.

Thank you for your explanation! 


-- 
Wolfgang

___
Twisted-Python mailing list
Twisted-Python@twistedmatrix.com
http://twistedmatrix.com/cgi-bin/mailman/listinfo/twisted-python


Re: [Twisted-Python] order of remote requests

2009-12-29 Thread Andrew Bennetts
Wolfgang Rohdewald wrote:
[...]
 I should have given more details, sorry.
 
 I am writing both the server and the client with twisted pb.
 The server (a game server) sends messages to four player clients.
 
 Say the game server sends messages A and B to a player client. 
 
 Is it granted that the player client always processes A first even
 if the internet routes the messages differently and B arrives
 first?

A PB connection uses a single TCP connection.  TCP guarantees that the
bytes will arrive in order (or not at all), so the messages will arrive
at the client in the order the server sent them, assuming there is one
persistent PB connection between each client and the server (which seems
likely from your description).

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, which might take 10s or even 100s of
milliseconds to fully process the message (and determine a reply, if
applicable)... then depending on the exact work required and exactly how
the OS schedules the threads, then B might be fully processed before A
is, even though A arrived first.

Apologies for such a pedantically precise and abstract answer, but what
exactly you mean when you say “processes” is a bit ambiguous.  I hope
this reply helps.

-Andrew.


___
Twisted-Python mailing list
Twisted-Python@twistedmatrix.com
http://twistedmatrix.com/cgi-bin/mailman/listinfo/twisted-python