[Xorp-hackers] XRL/Thrift: points for further work

[Bruce Simpson]

Here I'll outline a few points for further work.

Some of these might not make too much sense, until I've posted an update 
of where the XRL/Thrift work is currently at (to explain what's going on 
in XRL).

First, a few words on scalability:
 * Means different things to different people. In this case, it probably 
means the ability to parallelize, which may or may not involve threads.
 * One of the things which could be done, and is pretty much a 
prerequisite for threading, is to decouple the direct dispatch for the 
server-side of XORP RPC method calls, and implement a scheme similar to 
what we need in the XRL clients -- that is, we buffer the blob, giving 
us an opportunity to ship the request off to other threads, e.g. using 
work queues.
 * I am shortly going to re-post here some of what was discussed on 
xorp-dev@ privately a year ago to underline this.

A few words on clustering and AMQP:
 * AMQP is outside of the scope of this project, but it's worth a little 
thinking ahead for, given that it facilitates building scalable, 
fault-tolerant service clusters.
 * You can regard the use of AMQP, for Thrift RPC method calls, as a 
form of tunneled method call.
  * Please refer to my upcoming email on XRL/Thrift technical specifics, 
where I explain what tunneling the method calls involves.

 * Generally, there is only 1 transport layer session to the AMQP broker 
active at any time from a single client.
  * The tunneling wouldn't happen in libxipc as such; rather, we'd open 
an AMQP session per XRL target, and multiplex to/from this session for 
each service supported by that XRL target. Thrift, and some AMQP library 
yet-to-be-decided, would take care of the representation in that model.

 * The implementation constraints are likely to be similar to that of 
any other message-based transport.
   * See other message re Thrift 3rd party use, about why 
message-oriented semantics for Thrift clients are an issue.

 * The AMQP broker itself isn't a naming service; it's an RPC router.
   * Although an AMQP native Finder would be interesting. We have a 
number of producer/consumer relationships between XRL targets, which 
would be better implemented, in an AMQP world, using AMQP exchanges and 
bindings, and its Publish/Subscribe idioms.

thanks,
BMS