开云体育

When do you experience the 1100 errors, oho? During the IBKR maintenance windows and on weekends?

Take a look at the section of the TWS API Reference Guide. At the top of that section you'll find a little more detail about connection errors.

When we receive 1100 errors, we shortly after that receive code 1102 "Connectivity between IB and TWS has been restored- data maintained." so that nothing really needs to be done. The connection between our clients and TWS./IBGW is never impacted so that the clients do not have to restart.

We have never seen code 1101 "Connectivity between IB and TWS has been restored- data lost.". In case your client gets this message code, simply resubmit the market data requests your client had active before error 1100.

闯ü谤驳别苍

On Thu, Jan 5, 2023 at 11:30 PM, GreenGreen wrote:

* * Good point about OS resources, but my knowledge of OS are so limited that it looks like Python path is a bit easier.

Yeah, well... give it time and that stuff will become obvious. I was just taking an educated guess but if you're really curious you can actually read through the Python code for multiprocessing . Look inside process.py and subsequently context.py to get the final word on exactly what's happening "under the hood". Have fun :-)

On Thu, Jan 5, 2023 at 06:59 PM, 闯ü谤驳别苍 Reinold wrote:

take a peek at ib_insync for an excellent implementation

This is the best advice IMHO. Specifically, I'd take a close look at this code:

import asyncio

import ib_insync as ibi


class App:

    async def run(self):
        self.ib = ibi.IB()
        with await self.ib.connectAsync():
            contracts = [
                ibi.Stock(symbol, 'SMART', 'USD')
                for symbol in ['AAPL', 'TSLA', 'AMD', 'INTC']]
            for contract in contracts:
                self.ib.reqMktData(contract)

            async for tickers in self.ib.pendingTickersEvent:
                for ticker in tickers:
                    print(ticker)

    def stop(self):
        self.ib.disconnect()


app = App()
try:
    asyncio.run(app.run())
except (KeyboardInterrupt, SystemExit):
    app.stop()

It's the and basically looks like what you want.

Otherwise, unless you know exactly what to look for, sifting through random examples on the internet can be a wild goose chase.

Which TWS API version are you looking at, Shaun?

I just checked 10.19 "stable" and 10.20 "latest" and the reqHistoricalData request signature contains the boolean keepUpToDate and the chartOptions List;TagValue> for all languages. Check out "source/CSharpClient/client/EClient.cs"

The documentation at also shows both, the keepUpToDate boolean and chartOptions? list of TagValues.

闯ü谤驳别苍

On Thu, Jan 5, 2023 at 08:17 PM, GreenGreen wrote:

Even after reading buddy response, I am still puzzled why my code did not work.

If you read the man page for fork carefully you'll see it says... The child process and the parent process run in separate memory spaces. And, 闯ü谤驳别苍 kindly pointed out that the API works well when all threads run within the same process and have access to the same memory and global variables. So...

when you call:

p = Process(target = app.run)
p.start()
p.join()

and then, subsequently:

app.reqMktData(101, contract , '', False, False, [])
 
time.sleep(2)
app.disconnect()

You just might not be calling the functions in the process you think you are. In other words, you need to make sure you're referring to the same "app", because now there are two (one in the child and one in the parent).

So, the problem just might be that you're having the parent operate on things that are actually inside the child (or vice versa) and without doing some special IPC like shared memory etc this won't work. And even then, be careful because the API may not be designed to operate that way necessarily.

If you want the parent to "control" the lives of the children (count them, spawn a few, etc) that's one thing. But you can't just assume they share everything off the bat.. they share very little. A fork basically just starts a copy of the parent process in separate address space.

Think of it like running the same program twice from the command-line. If you did that you'd need a different client ID for each and two different tcp/ip sockets and probably call reqMktData on different contracts, right?

This is why I suggested you get more familiar with what fork does, since under the hood that's likely what a new Python Process does... just fork basically. Does this help?

Anyway, at the end of the day when 闯ü谤驳别苍 asks What is it that you are trying to achieve? he's being practical. However, when I suggested you read the man page for fork it was for you to learn something in an academic sense.

For the life of me IDK why you'd actually want to complicate things in the way you're trying to, lol. There's nothing wrong with using multiprocessing, I actually prefer it. But it's always easier to first use the facilities built into the OS before rewriting things in Python... you know, top, kill, pgrep, Unix pipes, the shell's ampersand operator etc. Then, if you're doing the same thing over and over whip something up in Python.

Just my 2cents. Good luck!

class order_manager(EWrapper, EClient):

? ? def __init__(self, entry_q, log_q):

? ? ? ? EClient.__init__(self, self)

if __name__ == '__main__':

? ? entry_q = Queue()?

? ? log_q = Queue()

?

? ? om = Process(target=order_manager, args=(entry_q, log_q))

? ? om.start()

What is it that you are trying to achieve? Why is the "standard" way of using TWS API insufficient?

TWS API runs a reader thread that receives all communication data packets from TWS/IBGW, decodes them, and calls the appropriate callback function to alert you about the response. That works well when all threads run within the same process and have access to the same memory and global variables.

But that will not work when the TWS API reader runs in a separate process. The nature of processes is that they cannot simply access each other's memory or directly call some method in a separate process. So you would need to implement your own API for your "client process" to communicate with your "TWS API process". That will be a lot of work even if you start with a library or module that provides a basic infrastructure. And the communication with TWS/IBGW will be slower since requests have to get from your client process first to your API process before they are sent to TWS/IBG and the responses will have to take the same way back.

闯ü谤驳别苍

PS. Before I forget.? Do yourselves a favor and lose all the? time.sleep() calls. TWS API is an asynchronous protocol where it is undetermined how long it will take for responses to your requests to arrive. If your client runs out of things to do between the request and the arrival of the response(s), the thread has to wait but never sleep.

The only acceptable use of sleep in relation with TWS API is when you need to? pace requests (for example to observe the 50 requests/second limit for older TWS/IBGW or the historical data download maximum requests rates). But in these cases, you delay the next request (the sleep is before the request) instead of sleeping after the request in the hope that some response came back while your thread slept.

Every language has some form of support for these asynchronous communications and for Python you may want to look at asyncio or take a peek at ib_insync for an excellent implementation.

And yes, even IBKR samples and those best selling "Get rich? fast with Python" books are just full of them. It's still wrong, dangerous, and borderline malpractice.

I think it might help you to thoroughly read .