开云体育

I am not familiar enough with Python but a couple of things maybe be generic

1- you have a side 'thread' that deliver you a condition that look like a HTTP return code, right ?
aiohttp.ClientSession() which will use same credentials, hence same session as your own main thread.
2- your own thread will place a bracket order (and look like you understood the purpose of 'transmit')
Your concern is that your order id will be messed up, but with what ?

Your code should better take some precaution as you seems to me to mix 2 different technologies, the SDK and the REST.
You better call self.reqIds(-1) at least once yourself and track the call back of nextValidId before you use app.nextOrderId().?
Read the sequence (init+operation+report) in
and consider the 2 call back openOrder and orderStatus. you SHOULD listen to it.
Start keeping thing simple, there is no harm to call self.reqIds(-1) and it is fast

I want to check if this is possible.

I am using the following code which queries a price using certain conditions from an api, the prices are returned to me asynchronously.

I want to place the order as soon as the query has been returned from the api. I put the app.placeorder into the async loop as shown below.

def BracketOrder(self, .....):


    # 1st part: Buy Adaptive Algo order
    opening = Order()
    opening.orderId = parentOrderId
    ./....
    opening.conditions.append(timeCondition)


    # 2nd part take profit or stop loss
    takeProfit = Order()
    takeProfit.orderId = opening.orderId + 2
    ....
    takeProfit.transmit = False

    stopLoss = Order()
    stopLoss.orderId = opening.orderId + 3
    ....
    stopLoss.transmit = False

    # # 3rd part: Sell Adaptive Algo order
    closing = Order()
    closing.orderId = opening.orderId + 4
    ...
    bracketOrder = [opening, takeProfit, stopLoss, closing]
    return bracketOrder


async def get_data(session, ticker):
    while True:
        try:
            async with session.get(url=f'api.exec.com') as response:
                if response.status == 200:
                    data = await response.json()
                    try:
                        df = pd.DataFrame(data)
                    except ValueError:
                        print("Data is not a valid float. Retrying...")
                else:
                    print("Received non-200 status code. Retrying...")
            await asyncio.sleep(1)  
        except Exception as e:
            print("Unable to get url {} due to {}. Retrying...".format(ticker, e.__class__))
            await asyncio.sleep(1)


    bracket = app.BracketOrder(parentOrderId=app.nextOrderId(), .........)

    for o in bracket:
        app.placeOrder(o.orderId, app.EQ_order_MKT(ticker), o)
        app.nextOrderId() 


async def main_loop(ticker_list):
    async with aiohttp.ClientSession() as session:
        ret = await asyncio.gather(*[get_data(session, tick) for tick in ticker_list])
        #return {ticker_list[i]: ret[i] for i in range(len(ticker_list))}
        return ret

def run_loop():
    app.run()

app = ib_class("127.0.0.1", 4002, 999)

#app.nextorderId = None
# Start the socket in a thread
api_thread = threading.Thread(target=run_loop, daemon=True)
api_thread.start()

asyncio.run(main_loop(new_portfolio.keys()))

I am worried that I will place to orders at the exact same time and the order id's will get messed up. Is there a way around this or does twsapi automatically mitigate this?

Oh wow, so this CMake builds a project with both pytorch and the TWS API in C++? Thank you so much

Yes. You're very welcome.

Just bear in mind that the process will be a little different for you since you're on Windows. For example, in order for me to get my stack ready I only needed to download the TWS API and the rest was set up using aptitude install cmake libtorch-dev libintelrdfpmath-dev.

I also don't know if WIndows supports genuine symbolic links so you may have to copy more stuff around than otherwise necessary.

In addition, you'll need to fiddle w/ the target_link_libraries for your specific needs. The bullet-points I mentioned should be most, if not everything, you need to "wrap your mind around" though.

-Good luck

BTW, besides the symbolic links, here are the changes I needed to make to their CMakeLists.txt:

--- orig        2023-08-18 12:41:21.180000000 -0400                                                            
+++ CMakeLists.txt      2023-08-18 12:39:07.488000000 -0400                                                    
@@ -1,11 +1,18 @@                                                                                              
 cmake_minimum_required(VERSION 3.18 FATAL_ERROR)                                                              
+include(CMakePrintHelpers)                                                                                    
 project(example-app)                                                                                          
                                                                                                               
 find_package(Torch REQUIRED)                                                                                  
 set(CMAKE_CXX_FLAGS "${CMAKE_CXX_FLAGS} ${TORCH_CXX_FLAGS}")                                                  
                                                                                                               
-add_executable(example-app example-app.cpp)                                                                   
-target_link_libraries(example-app "${TORCH_LIBRARIES}")                                                       
+include_directories("~/tmp/IBJts/source/cppclient/client/")                                                   
+include_directories("~/tmp/IBJts/source/cppclient/")                                                          
+file(GLOB SOURCES *.cpp ./client/*.cpp)                                                                       
+                                                                                                              
+cmake_print_variables(SOURCES)                                                                                
+                                                                                                              
+add_executable(example-app ${SOURCES})                                                                        
+target_link_libraries(example-app "${TORCH_LIBRARIES}" bidgcc000)                                             
 set_property(TARGET example-app PROPERTY CXX_STANDARD 17)                                                     
                                                                                                               
 # The following code block is suggested to be used on Windows.

Hope this helps a little.

On Fri, Aug 18, 2023 at 02:57 PM, blydon12@... wrote:

I don't want to use Cmake if I don't have to

I think you're probably making a mountain out of a molehill. As Gordon suggests CMake offers a ton of options and LibTorch needs that power since it can be configured to use disparate and exotic hardware. Otherwise you're better off (IMHO) just using Python and opencv + scikit or something.

But, if you decided to stick with LibTorch there must be a reason. And that reason, presumably, is you want the extra ability to configure everything. It shouldn't be that hard to merge your stuff in though. Especially if you're willing to take some [temporary?] shortcuts.

Gordon's suggestion to experiment on a small project is definitely spot on. I don't actually see why you can't experiment with your own TWS application though... just use the minimal CMakeLists.txt provided by LibTorch and leverage the following:

• symbolic links
• . EG: include_directories("~/tmp/IBJts/source/cppclient/client/")
• . EG: file(GLOB SOURCES *.cpp ./client/*.cpp)
• (to double check things are as you believe)
• . EG: target_link_libraries(example-app "${TORCH_LIBRARIES}" bidgcc000)

Then do your regular: cmake . and cmake --build .

I had the TWS sample going in short order and so I'm sure you'll be up and running in no time flat.

There are three ocaType options and only one of them allows MOC/MOO orders in the group. So I guess my concern is 67% valid :-)

We don't use OCA groups a lot but when we do, (more) guaranteed overfill protection is key so that we tend to use type 1 ("with block"). As you said, the two "with block" types reject MOC/MOO orders in the group but I guess the overfill risk for type 3 OCAs can be mitigated if triggers for the orders in the OCA are "far enough" apart. In other words, even in crazy market situation no two orders in the group would be eligible at the same time.

闯ü谤驳别苍

• There is a difference between "connection inactive" (when the farm is no longer needed) and "connection lost" (when there is a network failure or IBKR resets the farm)
• If there is any active subscription to real-time data, market data farms never become "inactive". They may be "lost" but in our experience are re-established within milliseconds without any impact on your client (unless you have a serious and ongoing network issue between you and IBKR).
• HDMS farms provide more general information services and are not limited to just historical market data download. If you dig into the TWS/IBGW logs you will see that internally, HDMS queries are made even for TWS API calls such as and and many (if not all) calls that have a object parameter. Apparently, HDMS farms carry and provide certain instrument related meta information for the instruments they are responsible for.
• There is absolute no need to "heartbeat" any of these servers and it actually may backfire on you since you may eat into you "pacing" budget. As I said before, market farms become inactive when they are no longer needed and get connected instantaneously and transparently when any of your API requests require them. If a connection that is needed is lost, it is also reconnected automatically without service interruption.

• slows down the response time fore requests
• fails requests with error 162 and message "no such data" or other errors
• fails requests with error 162 and some pacing violation message
• disconnects your client all together when too many pacing violations occur

Yes Out of scope of this forum
Yes Cmake sound crazy as another language to generate a language to generate a language to interpret a language.
But don't fight Cmake, it does exist because it's a pain to support multiple platform makefile and is now part of the landscape and for long.

Try to get a working makefile (or solution) for VS from somebody that have a working make PyTorch, it surely exist.? That's enough to deal with and give an example of a target file (to target with Cmake during weekend)
'roger'

I can only speculate.
What was the file path of the log you show extract here ?

Diag:
There are various log avail (including the GW display windows but require a lot of time to be analyzed (Best is to massage it as a CSV then open in Excel and use Excel to sort by kind or date or keyword or ...)
Generally people log everything themselves (you should), search on this forum about Log there are various thread on the subject.

Issue:
your report look to me like it should be interpreted as what messages say.
Looks like you look for a non existing instrument or no data exist for this instrument (Which one ?) Then you may have a logic that send a cancel (which is good in most cases )
but the request didn't behave as expected (was non longer answering something you expect) then you repeat the cancel.
Is it exactly 300 times ? if so then look for "300" in your code.

To be noticed: The difference between the error 366 (id 41690) and the error 162 cancel id (416904)? which is the same as the id: entry of your log.
Remember that many request have a "requestXXend" like historicalDataEnd, once done, your served and no need to trigger anything else aside of code housekeeping.
Cancel in is supposed to be used on a pending subscription. Over-Cancel is harmless as long as you know how to filter back messages.

?