IB API HOWTOs and Guidelines - For Beginners

[volpunter]

I believe you are a little confused yourself here:

First off, process/stream processing is the exact same as event processing. A new item that is streamed is considered a new event, or an "OnIncomingDataPoint" event, if you wanna call it that way. Many CEP engines are managing events under the hood, nothing more nothing less.

THen, your artificial distinction between OOP vs Process programming is non existent. OOP is a basic programming concept whereas "Process Programming" does not even exist in in regards to accepted CS terminology. OOP simply means that you build code on top of basic building blocks, objects. It has nothing whatsoever to do with how you process data. Each CEP engine, most every trading architecture is build on top of OOP coding principles. Each incoming data point is a class object instance.

So, I am confused what you are trying to say here, what really is your point?

glad you liked it, the code is really for demonstration, but as you can see it's quite simple

there is the issue of "OOP" vs "Process" programming. Many developers are only taught OOP these days, so they are lost when they have to deal with flow of information and process flow type of programming. OOP makes sense for "events" and managing objects visually. With data feeds and trader order flows, OOP is actually counter-productive and against the idea of Object Oriented Programming. Only HFT programming should be done in OOP, because of the events nature of the trade.

I keep being amazed by the level of incompetence from developers these days, they seem to be quite clueless and very "narrow" minded. They can do one trick and that's it.

 

[moskvich]

Hi guys,

i'm having problems writing code in C# that sends multiple orders to TWS. Sending 1 order works, so the issue might to be with the next order ID number. Also the same code (for multiple orders) works in IB Demo mode.....Appreciate any help!

 

[2rosy]

not bad in principle and theory, but won't work on a real server, I can see an issue with the nextOrderID and your implementation of the code for IB connection to the MQ server.

Nice try though, but needs a lot of improvement and testing first.

I had you on ignore but saw this post when I wasnt logged in.

I use the orderloader everyday. it extends a base class that is compiled; you cant see the source code for the base class.
class OrderLoader(BaseApp):
...
self.nextOrderID()

There is no implementation for IB connection to MQ server. Do you even know what MQ server is?

 

[Butterfly]

I use the orderloader everyday. it extends a base class that is compiled; you cant see the source code for the base class.
class OrderLoader(BaseApp):
...
self.nextOrderID()

There is no implementation for IB connection to MQ server. Do you even know what MQ server is?

of course I do, but did you even understand what I was referring to ? maybe English is not your first language or you are just another developer with a cognitive disconnect, this is so typical.

again have you tested your code with real trades (hundreds in a row) ? the way it is structured, I could see an issue with the "nextOrderID()" as that command will often lag.

I can't see your code working properly and I doubt you ever tested it. Claiming "I use the orderloader everyday" doesn't mean you actually use it everyday on trades. I do.

 

[Butterfly]

So, I am confused what you are trying to say here, what really is your point?

I was referring to programming design pattern and programming style. OOP is not the best option for managing orders and orders data, as the code can quickly become difficult to read and difficult to debug.

Creating classes to simply construct variables, or operate simple assignment operations is just adding opacity to the code eventually. It might look convenient and "interesting" in an "Object/Class Diagram" when you are designing a system, but eventually the code will be too structured for simple tasks.

I favor "imperative programming" for building trading applications, at least if they don't involve HTF orders or some special "real time" events.

My point is basically about building clean and simple programming codes for trading logic so they can be "debugged" and "modified" quickly without going through layers and layers of classes and functions that will break as soon as you make small changes.

 

[Butterfly]

A quick question:

I have a working Java example using reqMktData that retrieves a quote for a single stock.

I am not yet familiar with the API. What is the best practice for requesting quotes for many contracts, say 100 or 500?

J

you could try to submit a list of Contracts Objects to the IB Server on a given connection, but I doubt that would work. I suspect you would need to create several "connection" (different Client ID) to IB Server, with each connection (Client ID) corresponding to a Symbol you would like to retrieve the MktData from.

Again IB APIs might not be the best solution for Market Data feed. Their implementation seems to be limited, and there are reports of delays from the IB Server replies regarding accurate MktData.

Quote data feeds are best if they are implemented outside the IB APIs. You can still mix those implementation and the IB APIs in your code, but it won't be IB running the MktData part of your code.

 

[2rosy]

of course I do, but did you even understand what I was referring to ?

So what do you think MQ server is? Why were you referring to it? It's irrelevant.

again have you tested your code with real trades (hundreds in a row) ? the way it is structured, I could see an issue with the "nextOrderID()" as that command will often lag.

I wrote nextOrderID() myself. You don't even know how it is implemented; it's in the compiled base class *pyd

for those curious here's the implementation. feel free to point out the lag

def nextOrderID(self):
        self.wrapper.orderID += 1
        return self.wrapper.orderID

back to my ignore list

 

[volpunter]

That is total crap, I would claim 90%+ Order Management Systems, and data connectivity as well as execution APIs are written on top of OOP principles. Not one serious OMS on the other hand has ever been built through Python or related brethren. At least stick to the facts here, unless you have ever worked at an investment bank, hedge fund, or other buy side firm and can attest to have seen an OMS written in Python or non OOP language please do not falsify facts.

Whether something "breaks" when you make "small changes" is a function of your coding capabilities or let me put it better, it is a function of your project design and architectural capabilities.

Saying that OOP languages disqualify one from writing top notch OMS and execution related software code totally disqualifies your credibility here.

I was referring to programming design pattern and programming style. OOP is not the best option for managing orders and orders data, as the code can quickly become difficult to read and difficult to debug.

Creating classes to simply construct variables, or operate simple assignment operations is just adding opacity to the code eventually. It might look convenient and "interesting" in an "Object/Class Diagram" when you are designing a system, but eventually the code will be too structured for simple tasks.

I favor "imperative programming" for building trading applications, at least if they don't involve HTF orders or some special "real time" events.

My point is basically about building clean and simple programming codes for trading logic so they can be "debugged" and "modified" quickly without going through layers and layers of classes and functions that will break as soon as you make small changes.

 

[Butterfly]

So what do you think MQ server is? Why were you referring to it? It's irrelevant.



I wrote nextOrderID() myself. You don't even know how it is implemented; it's in the compiled base class *pyd

for those curious here's the implementation. feel free to point out the lag

def nextOrderID(self):
        self.wrapper.orderID += 1
        return self.wrapper.orderID

back to my ignore list

God, what a precious sensitive little princess you make, how old are you again ?

I can only hope you are not working professionally as a developer, so that no company has to suffer your silly attitude when questioned about the weakness of your code.

Still, regarding NextOrderID, you are not keeping track of it if you run another session that same day. Like I said, good effort for theory, but need a lot of more work before it can be used in the real world.

have a good ignore list :rofl:

 

[Butterfly]

That is total crap, I would claim 90%+ Order Management Systems, and data connectivity as well as execution APIs are written on top of OOP principles. Not one serious OMS on the other hand has ever been built through Python or related brethren. At least stick to the facts here, unless you have ever worked at an investment bank, hedge fund, or other buy side firm and can attest to have seen an OMS written in Python or non OOP language please do not falsify facts.

Whether something "breaks" when you make "small changes" is a function of your coding capabilities or let me put it better, it is a function of your project design and architectural capabilities.

Saying that OOP languages disqualify one from writing top notch OMS and execution related software code totally disqualifies your credibility here.

You are living in the past, yes my point is that OOP is being overused for a lot of things that shouldn't consider OOP. This has nothing to do about being serious, credible or anything, it's just a question of choice and programming habits. If you think that Python is not taking over Java or other OOP languages, then think again, it's coming now. Python is now replacing Java as the main learning programming languages in most US and European Engineering Universities. Not saying OOP will disappear, but it will no longer be the default programming style for business applications out there.

As for seeing a full OMS in Python, I have seen OMS and OMS related projects that are being ported to Python, projects by large Investment Banks with multi-million USD budget. Again, not sure why it's so incredible to consider it couldn't happen. Again for those living in the past, it surely can't happen.

As for "small changes" breaking code, maybe if you were working on large scale projects with hundreds of developers, you would get it. When you are working alone, those "small changes" are indeed your own responsibilities.

I don't think you have any authority here, or anywhere else for that matter, to claim my opinion about those programming techniques should automatically disqualify me or my credibility. You might not like or understand what I am saying, but that doesn't take away the facts I have mentioned above.You choose not to agree with them is your own personal choice and bias, not mine.

Also, I have built enough OOP codes for several hundreds projects to have formed an educated opinion about those matters. I like OOP but I think that for too many projects, it's not the right programming style to have. Problem is that most developers are one trick monkeys, they can't learn anything different once they have been taught one way.