sure and to back up your claims you can of course mention to all of us which large bank or asset management firm runs their OMS written in Python. You are delusional. I am willing to bet the farm that you either evade to provide firm backup or come up with some BS because I have been in this game way too long to know that there is nobody in their right mind who would write an OMS in python. And there are a million reasons for that. But before I get into that I first wanna hear some backup before wasting any more of my precious time. Until then you made some outrageous claims re OOP languages and it is you who looks stupid based on the current status quo. Help us change our perception about you...
I couldn't care less what your perception of me is, and I have no intention to persuade you otherwise, and since when the status quo is a source of change ? never been, and you know it. This is just the beginning of change, I know that all those silly Java Applications Servers I have been working with in the last 15 years are going to disappear in the next 5 years for a number of technical reasons. Like I said, you can stay in the past or look into the future, and the future is not pure OOP and Java. As for naming names, have you worked with every big corp in the Industry ? let me guess, no. I know SocGen and BNP are working on those portage, of course they are not going to switch everything overnight but we are getting there. Still a work in progress. Anyway, what's your beef with Python as this seems to be the main question here ?
if you are talking about trends and changes all of a sudden then I recommend you work on improving your English skills. So far your outcry about OOP reflected your opinion about the status quo. I can only repeat, your assessment that OOP languages are ill suited to OMSs is not only complete and utter nonsense. It also shows you do not even understand what OOP really means. Python, R, and a number of interpreted languages heavily borrow from OOP concepts and so it is not even sure what your gripe is. Certainly the status quo does not reflect that any major financial firm has so far much confidence in Python as a tool to develop major production stealth execution systems. And I do not see Python installed anywhere else than on quant developers' and quant strategists' desk. Get real!!!
and those are utter lies you put up. Neither BNP nor SocGen are working on anything that relates to Python at least not when it comes to execution related system. Guess what, both houses in fact completely re-wrote their code bases and retired their C++ code bases for all DMA execution related algorithms, for their derivatives pricing engines, front-office Excel plugins, and numerous others. Guess which language...C#. Nobody considers Python a serious contender to handle such monstrous tasks. Python was never designed to do that anyway. It was designed as a light-weight "glue" to patch together lose ends, to do some quick testing of algorithms. You may wanna read up on the origins of Python before you swing around with your little prick. Idiot.
There is a limit of separate connections to TWS - it is about maximum of 8 clients connected that can be handled by TWS. You do not submit anything to IB server directly. It is done through TWS or Gateway. The way to have multiple quotes updating up to maximum of 100 (unless certain conditions are met and this limit can be increased) is to submit 100 requests for market data usually done in a loop with different id (first field - just put some integer there different from previous request) and obviously with required contract information for desired symbol. This ID will be used when TWS returns quotes. This ID is user generated and has nothing to do with orderID - just put numbers 0 - 99 that would map to your symbol list.
oh oh, someone is an angry character and talking out of his arse, again. you do not have access to every IT projects at BNP or SocGen, so how can you claim it's all lies ? maybe your own ignorance is being exposed here and you can't accept it. Python is not about to "glue" anything, or being a small hack. Python is about simplicity and bringing back the fun of programming to developers instead of worrying about frameworks and other OOP non-sense. and again you seem to confuse OMS with a lot of things. There are hundreds of OMS related projected that can be built with Python and are being built with Python. OOP and Java or inferior C# certainly do not have the monopoly on that market.
well at least I can speak several languages, can you ? probably not, Python can do OOP you silly idiot, but it's not required. That's the beauty of it. And what is it with your "Status Quo" thing ? you have no clue what's being done these days, you don't have access to every projects on the planet, so stop making silly claims about status quo, you have no fucking clue and it feels like you are trying to prove yourself by hiding behind some "invisible" status quo thing, like we should give a fuck about it.
Thanks for your answers. My latest implementation simply loops over an array of symbols (1 client ID). I plan to extend it with a throughput constraint to avoid hitting the 50 messages per second limit - something I'm putting in place now. A delay of a few seconds for ~500 symbols is no problem for my needs.
apparently from the answers above, you can submit some kind of "id" to the IB Server for each contract MktData request, so the trick will be to manage and catch those IDs to keep track of the symbols and their MktData. I do my symbol quote feed outside IB APIs, much easier. Not feeling comfortable having MktData and Order process going through the same MQ feed.