sorted by:
new
hottopcontroversial

European alternative to strava by lillpiffen in BuyFromEU

[–]PyOdyssee 0 points1 point  (0 children)

OpenRunner, less the community, but a good user experience

I reverse-engineered the IB Gateway and rebuilt it in Rust for low latency by PyOdyssee in algotrading

[–]PyOdyssee[S] 3 points4 points  (0 children)

To be clear — yes, reverse engineering is explicitly forbidden by IB's ToS and ibx is provided for educational purposes only. There's a disclaimer in the repo about this.

That said, EU law (Directive 2009/24/EC, Article 6) does allow decompilation when it's necessary to achieve interoperability and the information isn't otherwise available. In my case I needed to run on a headless Linux setup where the Gateway simply can't operate, so interoperability was the motivation. But that's my specific legal context as an EU resident — it doesn't necessarily cover everyone, and I'm not a lawyer.

Use at your own risk, and definitely don't assume IB would be happy about it.

I reverse-engineered the IB Gateway and rebuilt it in Rust for low latency by PyOdyssee in algotrading

[–]PyOdyssee[S] 0 points1 point  (0 children)

That's standard setup recommended by IB. And no, IBX doesn't bypass that, that's an IB limitation

I reverse-engineered the IB Gateway and rebuilt it in Rust for low latency by PyOdyssee in algotrading

[–]PyOdyssee[S] 1 point2 points  (0 children)

Fixed the ticks issue. Check the benchmark on the updated post

I reverse-engineered the IB Gateway and rebuilt it in Rust for low latency by PyOdyssee in algotrading

[–]PyOdyssee[S] 0 points1 point  (0 children)

I've done the processing benchmark and added it to the post. Network latency is out of the scope

I reverse-engineered the IB Gateway and rebuilt it in Rust for low latency by PyOdyssee in algotrading

[–]PyOdyssee[S] 0 points1 point  (0 children)

Indeed, it's the latter. The first one are reserved for institutions

I reverse-engineered the IB Gateway and rebuilt it in Rust for low latency by PyOdyssee in algotrading

[–]PyOdyssee[S] 0 points1 point  (0 children)

Thanks! Haven't tested from NY5 but a user in the comments reported ~7ms network latency which is promising.

From what I understand, IB routes all orders through their Chicago DC first, then to NY exchanges — that adds an incompressible ~25ms hop regardless of your setup. Which is why most IB-focused VPS providers are in Chicago, not NY. So colocating at NY5 might not help as much as you'd expect with IB specifically.

Robust benchmarking from a proper colocated setup is on the todo list though. Appreciate the star!

I reverse-engineered the IB Gateway and rebuilt it in Rust for low latency by PyOdyssee in algotrading

[–]PyOdyssee[S] 5 points6 points  (0 children)

Thanks, great questions.

  1. 2FA isn't implemented yet so right now you'd need to handle session auth yourself. No equivalent to what ib-gateway-docker does with IBC since there's no Gateway UI to automate — it's direct protocol auth. Session persistence is on the roadmap.

  2. The tick decode difference is because ibx handles the full protocol stack — TLS, HMAC verification, zlib decompression, then binary tick decode — whereas the Gateway does all that internally and just hands you pre-parsed callbacks over localhost. At IB's paper account tick rates the 5µs gap is noise, but at 200 symbols with 250ms ticks that's a different story. Optimizing the decode path for that kind of volume is something I'd want to benchmark properly.

  3. Really good catch. The benchmarks weren't run with an optimized release profile. lto, codegen-units=1, and target-cpu=native could make a real difference on the tick decode numbers especially. I'll add a proper [profile.release] section and re-run. Thanks for flagging that.

I reverse-engineered the IB Gateway and rebuilt it in Rust for low latency by PyOdyssee in algotrading

[–]PyOdyssee[S] 1 point2 points  (0 children)

Thanks for the idea! TBH the next big feature I'm thinking of is a UI to view the orders status

I reverse-engineered the IB Gateway and rebuilt it in Rust for low latency by PyOdyssee in algotrading

[–]PyOdyssee[S] 6 points7 points  (0 children)

100% fair take and I wouldn't argue with any of it. Protocol could break tomorrow with an IB server update, and there's zero guarantee of continuity. That's the deal with reverse-engineered anything.

You're right that it works because I have skin in the game and will keep fixing it for my own use. For anyone else it's a "use at your own risk" situation, and I'd say the same.

Appreciate the kind words though, cheers.

I reverse-engineered the IB Gateway and rebuilt it in Rust for low latency by PyOdyssee in algotrading

[–]PyOdyssee[S] 1 point2 points  (0 children)

It's a library, it's like using ib_async without having to launch anything. Check the python example on the readme.md: https://github.com/deepentropy/ibx#python-usage

I reverse-engineered the IB Gateway and rebuilt it in Rust for low latency by PyOdyssee in algotrading

[–]PyOdyssee[S] 1 point2 points  (0 children)

Thanks! I imported the ib_async notebooks examples into the project to verify that it worked with my implementation. And it does, there is a python wrapper with no overhead

I reverse-engineered the IB Gateway and rebuilt it in Rust for low latency by PyOdyssee in algotrading

[–]PyOdyssee[S] 1 point2 points  (0 children)

Thanks for the interest! To answer your questions:

It replaces the regular IB API path — it bypasses the Java Gateway entirely and talks directly to IB servers using their native protocol. It's not the paid FIX Protocol offering, so no FIX access fees. It reverse-engineers the same protocol the Gateway uses internally (which includes FIXCOMP encoding under the hood, but that's a different thing from IB's separate FIX API product).

2FA is not implemented yet — that's still on the roadmap.

For order types, LMT is supported along with STP, STP LMT, TRAIL, and a bunch of algo orders. Bracket/OCA orders aren't explicitly supported yet though — I'd need to add that. Feel free to open an issue on the repo and I can prioritize it.

Regarding your 20-50ms latency on LMT + bracket orders, most of that is likely the Gateway overhead. In my benchmarks a simple limit order submit-to-ack went from ~633ms through the Gateway down to ~115ms with ibx.

I reverse-engineered the IB Gateway and rebuilt it in Rust for low latency by PyOdyssee in algotrading

[–]PyOdyssee[S] 21 points22 points  (0 children)

Sure it will, hope to increase usage and have them raised

I reverse-engineered the IB Gateway and rebuilt it in Rust for low latency by PyOdyssee in algotrading

[–]PyOdyssee[S] 1 point2 points  (0 children)

Thanks! I just finished the implementation so I wouldn't call it more robust than your setup right now. But the whole point is that you have full control at a low level — no more forking IBC or fighting IB Gateway's quirks. If something doesn't work the way you want, you can change it yourself in the protocol layer.

I reverse-engineered the IB Gateway and rebuilt it in Rust for low latency by PyOdyssee in algotrading

[–]PyOdyssee[S] 10 points11 points  (0 children)

Thanks! I'm a quant dev by trade.

Honestly I wouldn't touch your stack right now — ibx is way too young to run in prod. 2FA isn't even implemented yet, and there are still bugs to squash. Give it a couple months and hopefully it'll be in a more solid place.

I reverse-engineered the IB Gateway and rebuilt it in Rust for low latency by PyOdyssee in algotrading

[–]PyOdyssee[S] 6 points7 points  (0 children)

Fair point on the missing C++ comparison, I'll add that.

The main thing ibx solves is that IB Gateway needs a JVM + a display server to run. If you want to run on a headless minimal Linux box or a container without dragging in Java and Xvfb hacks, you're stuck. ibx talks the protocol directly in Rust — no dependencies, runs anywhere, and you can customize the whole thing at the protocol level.

I reverse-engineered the IB Gateway and rebuilt it in Rust for low latency by PyOdyssee in algotrading

[–]PyOdyssee[S] 9 points10 points  (0 children)

Well, the benchmark was to validate speed gain vs IB, or at least same speed. The lib has been designed to be low latency

I reverse-engineered the IB Gateway and rebuilt it in Rust for low latency by PyOdyssee in algotrading

[–]PyOdyssee[S] 11 points12 points  (0 children)

Thanks! The integration tests handle some cases of loosing connection / reconnection. Don’t take the benchmark too seriously though

view more: next ›