IB Protocol Buffer

45 views
Skip to first unread message

Glenn H Tarbox, PhD

unread,
Jul 20, 2008, 2:53:01 PM7/20/08
to sage-f...@googlegroups.com, sage-dsageng
I've put up a repo at:

http://tarbox.org:8080/?p=ibProtoRpc/.git;a=summary

to maintain the work I'm doing to build the IB Protocol Buffer RPC
implementation. The repo will likely change rather dramatically once I
have things working because this repo basically a superset of another
repo to build proper RPC support for Protocol Buffer both at the
protocol definition level and its java implementation

http://protorpc.likbilen.com/index.html

Also, here's a twisted Protocol Buffer implementation at

https://launchpad.net/txprotobuf

The latter is new and is basically attacking initial integration whereas
protorpc wants to address the broader problem. The two groups are
talking and I'm pretty sure there will be a unification at the protocol
definition layer (i.e. the .proto files defining RPC specific
information)

I'll follow both and maintain an up-to-date set of repos for those core
capabilities and any deviations as well as the super-set supporting IB.
In the next few days I'll have working examples over protobuf.

I'll also be posting a distributed object implementation which provides
synchronous and asynchronous client interaction. Turns out, that a well
protected thread was the key to making things easy. Twisted's
blockingCallFromThread() provides the "illusion" of blocking so normal
sage code "just works" yet the client is able to maintain interaction
with asynchronous callbacks and exogenous events. My current
implementation can marshall all Sage objects which support dumps() and
uses distributed Sage kernels as compute servers and event handlers to
ingest live data.

Unfortunately, that code is in a state of disrepair as I backed out the
pyprocessing layer but will emerge in the next few days. pyprocessing
support for local processes under the Notebook will be abstracted using
a consistent interface definition for both remote and local processes.
Its unclear whether supporting the pyprocessing sockets/queues is an
advantage and the current implementation simply uses a connection to a
port which just happens to be local. There is utility to exploiting the
shared memory capabilities of pyprocessing but that will come in time.

I'm also going to do some prototyping with xml-rpc using Apache's
infrastructure. However, its pretty clear that Protocol Buffer is a
better match for the finance work.

-glenn

--
Glenn H. Tarbox, PhD || 206-494-0819 || gl...@tarbox.org
"Don't worry about people stealing your ideas. If your ideas are any
good you'll have to ram them down peoples throats" -- Howard Aiken

Reply all
Reply to author
Forward
0 new messages