开云体育

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 .

hymagik is correct about the somewhat messy C++ Decimal support and the fact that IBKR has selected a decimal size of 8 bytes (64 bits). To be more precise, IBKR decimal uses a "MathContext with a precision setting matching the IEEE 754R Decimal64 format, 16 digits, and a rounding mode of HALF_EVEN.". I also fully support when hymagik says 'Once in "Decimal" you should stay in Decimal'.

• built-in "decimal" type for C#
• the IBKR class Decimal that wraps around the native BigDecimal in Java
• the module "decimal" in Python.

There are really no settings you can change. You would have to use a TWS API Version of at least "163" for any of the fractional size rules to work. rossh_yh mentioned that "163" is available in TWS API V10.10 and later. And it sounds like IBKR now requires fractional size support for AUD.USD real-time data.

• for C++ in "CppClient/client/EDecoder.h"
• for C# in "CSharpClient/client/MinServerVer.cs"
• for Java in "JavaClient/com/ib/client/EClient.java"
• for Python in "pythonclient/ibapi/server_versions.py"

Your client can also be aware of the maximum API version it understands and, after connection with TWS/IBGW, the highest common version. This is somewhat language dependent again, but in python, for example, these two lines below should be able to print the API version for you and it should print a number of 163 or higher for fractional siye support.

from ibapi.server_versions import *
print( MAX_CLIENT_VER )

闯ü谤驳别苍

PS. Excuse my PSL level python skills (Python-as-a-Second-Languge) but we speak Java at home