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
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
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
I have targeted LMAX through their FIX gateway. What in the Java API doc is inaccurate? Care to explain?