LMAX inside spread liquidity
- Thread starter FutureScalper
- Start date
IF you adapt LMAX to Hyperscalper i want try it
Well it's not "if" or "whether" but "when" and an Alpha test should be
going in a week. Won't be that difficult. As I said before, the question
is whether we can exploit enough liquidity to price advantage ! PM me or
whatever...
HyperScalper
Just an update on our migration of complex software to
LMAX.
We are using their Java API. This is a complex multi-thread
migration of software originally designed for Dukascopy to
the LMAX exchange.
First of all, their Javadocs are wrong. This is rather
unprofessional of them.
I have asked a handful of reasonable questions of their
support. In fact, we are not just "playing around" but have
opened a Live account with them and it is funded.
So I get this from the Head of their Integration Department
that we should use "trial and error" to figure out their
API. I repeat "trial and error". I'm not going to embarrass
by posting their entire email. That quote is enough !!
WHAT? Are you kidding me? If they keep on this this
attitude we'll go directly to their CEO and get this thing
straightened out.
Yes, we'll be able to do the migration of our complex software
to LMAX (by "trial and error") but wouldn't you expect a "reasonable" level of
support from such an organization as LMAX?
I'll keep y'all posted...
HyperScalper
LMAX.
We are using their Java API. This is a complex multi-thread
migration of software originally designed for Dukascopy to
the LMAX exchange.
First of all, their Javadocs are wrong. This is rather
unprofessional of them.
I have asked a handful of reasonable questions of their
support. In fact, we are not just "playing around" but have
opened a Live account with them and it is funded.
So I get this from the Head of their Integration Department
that we should use "trial and error" to figure out their
API. I repeat "trial and error". I'm not going to embarrass
by posting their entire email. That quote is enough !!
WHAT? Are you kidding me? If they keep on this this
attitude we'll go directly to their CEO and get this thing
straightened out.
Yes, we'll be able to do the migration of our complex software
to LMAX (by "trial and error") but wouldn't you expect a "reasonable" level of
support from such an organization as LMAX?
I'll keep y'all posted...
HyperScalper
Just an update on progress. First of all has anybody reading this had
significant experience with their Java API ? Never hurts to have
company...
Coming from the Dukascopy API, we're having to emulate the entire
Orders State and Collections subsystem, and to cross-translate
number formats and size specifications LMAX<-->Dukascopy. The
migration is going well but it's a lot to emulate behind interfaces
so that the core of our logic can remain "Dukascopy-esque"
Again, if anybody has written a significantly complex LMAX client
using their Java API it would be good to know. Comrades in
suffering... LOL Anyway, we're getting Market Data, that's fairly
easy, but the Order Entry component will be the real acid test.
The software has to handle dozens of simultaneous orders, so
it's not trivial.
Will post progress...
HyperScalper
OK, mastering the LMAX Java API is a "do it yourself" type of adventure, especially if you're writing a non-trivial piece of production code. As usual, the demo code they provide either doesn't work, is slightly out of date, or doesn't provide "professional" level techniques. Their support is "reluctant" to help much, but that's what makes it "fun"
However, persistence pays off, and as a progress report, we're about 3 days away from a working multi-order HyperScalper micro scalping platform Alpha level test of liquidity. All of this work, to find out how much "wholesale liquidity" we can find inside the Bid and Ask spread... It largely emulates Dukascopy's API IEngine interfaces, which is allowing our core logic to remain largely untouched.
BY THE WAY, IS ANYBODY USING MT4 ON LMAX? I see that a number of introducing brokers for LMAX are offering MT4. My partner has some existing EA's which could be used for some other trading purposes.
Thanks,
HyperScalper
Is this link something Lmax provides ?
Here is a high level summary of development so far, as I am migrating
a complex multi-threaded, multi-order scalping platform from Dukascopy
to LMAX. The goal here is to preserve the core logic but, in order to do
that, we had significant challenges in emulating the Dukascopy API and
Order management concepts on top of LMAX orders.
Here we are using the Java API, which presents lower level concepts and
is missing many of the higher level facilities we relied upon in the Dukascopy
API, such as the Order IEngine, and the simple ability, for example, to
change the Price of a Live order. With Dukascopy, it's simple to change
the price of a live order, but this high level concept is absent in the LMAX
Java API and thus we will have multiple Cancel/Place cycles underlying
the filling of a single high level Order.
1) Mapping a high level "Dukascopy style" order to underlying LMAX orders.
I've had to emulate the Dukascopy IEngine interface, which handles all of
order state, as well as IOrder states and operations such as IOrder.setPrice.
Within this emulation, we may use dozens of underlying LMAX orders to
achieve a single high level order fill objective, given that we will need to
change price during execution, which requires us to Cancel/Place a new
LMAX Limit order.
2) Emulating Dukascopy's IEngine was a challenge, as we had to "host"
Dukascopy IStrategy code, create a SingleThreadedExecutor, and subclass
"public class MyThreadPoolExecutor extends ThreadPoolExecutor ..."
to give us access to "afterExecute" so that we could "batch" together
multiple IOrder emulated operations, such as change price, lot size, add
StopLoss, add StopProfit, etc. And then at the end of the Thread task, on the
same Thread, the afterExecute Java thread pool would "batch invoke" the code
which performs all of the required operations on the underlying LMAX Order(s),
including Cancel/Place sequences, when price changes... Also, because multiple
LMAX orders are needed to support our high level objective, we are not able
to use LMAX Order StopLoss and StopProfit operations, as they represent
only a portion of our high level IOrder's objective...
3) Dukascopy allows us to differentiate facilities by a user-supplied "Order Label"
so we can differentiate activity by parsing the Order Label, thus ignoring orders
which are not related to the current client's orders. LMAX does not appear
to allow us to assign a meaningful Order ID in this way, so we are likely to
have to implement 1) a database which preserves Dukascopy style order
Labels mappings to LMAX Orders, or 2) much easier, just use multiple
LMAX accounts, each for a specific trading BOT or client trading platform.
4) Differentiating between actions of our Client, and actions of the LMAX
platform or another client. By assigning "instructionIDs" in our client
which are always AlphaNumeric, then when we receive instructions IDs
which are purely Numeric, we know the activity did not originate from
this client this is not a comprehensive solution, and it looks like we'll
have to implement a database.
However, without going into further detail, their Java API (and, by extension,
I suppose, their .NET API which is very similar in its semantics) is quite
powerful in permitting the multi-threaded management of multiple orders,
on both sides of the market simultaneously, with very good response times.
But it makes me appreciate the high level facilities offered by the Dukascopy
API which we have to emulate here at LMAX.... We're still a couple of days
away from a minimally working platform and, by substantially emulating
the basic Dukascopy API, we will then be able to adapt many of our existing
BOTs also, but many other high level constructions such as Indicators
are areas which I am hoping not to have to emulate at all, and we can just
grab that information from another streaming source such as Dukascopy.
And all of this work is to get "wholesale, or better than retail" pricing liquidity,
which we haven't been able to validate yet. Lots of work, hoping for results...
HyperScalper
Last edited:
I have targeted LMAX through their FIX gateway. What in the Java API doc is inaccurate? Care to explain?
Just an update on progress. First of all has anybody reading this had
significant experience with their Java API ? Never hurts to have
company...
Coming from the Dukascopy API, we're having to emulate the entire
Orders State and Collections subsystem, and to cross-translate
number formats and size specifications LMAX<-->Dukascopy. The
migration is going well but it's a lot to emulate behind interfaces
so that the core of our logic can remain "Dukascopy-esque"
Again, if anybody has written a significantly complex LMAX client
using their Java API it would be good to know. Comrades in
suffering... LOL Anyway, we're getting Market Data, that's fairly
easy, but the Order Entry component will be the real acid test.
The software has to handle dozens of simultaneous orders, so
it's not trivial.
Will post progress...
HyperScalper