Application of my fault-tolerant real-time technology

J

Joel Reymont

Folks,

I developed a fault-tolerant (99.999% uptime) and infinitely scalable poker server based on technology that telcos use to build their 911 telephone switches.

I built a cluster that can be reconfigured on the fly with new nodes or machines added or taken away at any time. I'm interested in applying the same technology to real-time trading systems and backends. Can you recommend a niche?

The technology is the Erlang/OTP (Open Telecom Platform), more on it at http://www.erlang.org. It has been developed for soft real-time systems and have been used successfully for a few years. Fault-tolerance, fail-over, take-over is built right into the platform and concurrent processing is one of its strengths.

Erlang comes with a real-time replicating in-memory database called Mnesia. It was originally designed for real-time call billing and the maximum size of the database is 4Gb. It can be written to disk on one or more nodes in a cluster and is kept in-memory on all others. Changes are propagaged in real-time on all nodes and fault-tolerance is built in. The database will recover itself after a crash and new nodes coming online will automatically receive the latest copy.

Erlang is particularly suitable for writing network servers, proxies, protocol converters, etc. I'm thinking of real-time data feeds, automated and program trading but will apreciate any advice and suggestions.

Thanks, Joel

--
http://wagerlabs.com/tech
 
Joel:

An intriguing concept but-

I looked at the Erlang reference. Since the documentation is 200+ pages perhaps you can answer this question without my having to read it all.

Does the language allow the user to write programs which can create a network of machines which act in a fault-tolerant (99.9999%) manner or is it a language to control fault-tolerant hardware? Or both?

Thanks.
 
Jack,

The language/platform allow you to easily write programs that act in a fault-tolerant manner on cheap off-the-shelf hardware. Same thing with clustering.

Erlang was designed at Ericsson to write real-time telecom software. Call termination, handling, billing, all that is real-time and cannot fail. Switches can be down for 5 minutes out of a year, hence 99.999% availability.

Granted, you DO have to properly design things and take advantage of platform features but at least all the needed tools are there.

I took advantage of these tools to build my poker software but I have not passion for it so now I'm looking to apply the technology to trading.

Lets say you have multiple brokers to route orders to and that you normally prefer one over the other. You can automatically reroute your trades to a different broker when loosing connection to the first one.

You can have stand-by trading apps (processes) that take over failed ones so that you don't loose opportunities and money.

Processes within Erlang are very lightweight so you can afford to model your trading systems in a concurrent fashion, doing things on every tick, etc.

I'm joelr@well.com on MSN Messenger if you want to chat.

Joel
 
Very cool.

From the Erlang Website:
Open-Source Erlang

Erlang is a programming language designed at the Ericsson Computer Science Laboratory. Open-source Erlang is being released to help encourage the spread of Erlang outside Ericsson.
More...
Tomas Abrahamsson has released a new version (0.92) of the user contribution py_interface... The py_interface package is acting as an Erlang node written in 100% Python,... . It features a callback oriented single-threaded programming model.
More...
 
Joel Reymont,

With automated trading systems, controlling the access and accuracy of your data from the exchange is probably the most significant problem. Maintaining a fault tolerent trading system is important, but not as difficult.

If you can come up with a technology that eliminates these potential problems, you will make a lot of money.

Runningbear
 
Can you give me an example of how I would control the access and accuracy of the data from the exchange? It sounds like just the right problem to solve, I just need to understand the problem a little better. Thanks!
 
Well having a technology that could monitor 2 or more data feeds, matching and confirming the accuracy of the data as well as monitoring and reporting on excessive latency in either feed is an example. I hope that helps.

Runningbear
 
RunningBear, do you want to be my project "mentor"? Shoot me an email to joelr@well.com please or page me on MSN Messenger using the same email address.

What two data feeds would you pick for starters?

How would you match and confirm the accuracy? We are talking about matching ticks, right? This would require that the data feed providers in question send you an exchange-provided time stamp with every tick, right?

I'm talking to someone who basically has the same idea. They also suggested that with IB, for example, there are multiple entry points into the platform and if one of them fails the "proxy" that I am to build can switch to a different entry point.

This is a very interesting suggestion and I'm eager to build a prototype!
 
A couple of things, Erlang is an interesting language, but probably won't be used to
write the low level data scrubbing code.

One thing Erlang can probably do well is schedule across a cluster of compute
servers, it won't replace TIB (or ACE or something of that sort), but can probably
be used to replace the bridges between RV and JMI, say, if it can do the context
translations faster.

Depending what type of trade you are looking at, for exchange traded stuff
(which I believe 99% of ET focuses on), low latency, in my opinion, is more
important than fault tolerance. As an estimation of magnitude, say 400
instruments with 10 updates per second.

But maybe better application would be for exotics, that would need massive
amounts of computation. Say a standard IRD (interest rate derivative)
with a few tranches (do a Google lookup), would require a fair amount
of Monto Carlo to model correctly, so Erlang can maybe monitor the scenario
threads and make result aggregation better.

Just my $0.02
 
Thanks for the suggestion Rufus!

How about this... There's apparently no clear leadership in the heavy-duty tick-based trading and optimization area.

Do you think such a platform is needed and if so what features do you think will be crucial or important?

I'm also thinking of having the platform accept EasyLanguage as input, to make it easier for those not wishing to take up Erlang.

Thanks, Joel
 
You must log in or register to reply here.
Back
Top