Hi 闯ü谤驳别苍, sorry for posting about this topic again, but I finally extensively tried what you suggested and I now understand what you meant by making the order self destruct.

I ran into the problem where an order did not fill at all and it did not self destruct after 3:50, so I am trying to take your advice into consideration now using the timecondition. Is this the correct way of doing it? I will try it on paper trade tomorrow once I have figured it out.

To ensure that if

1. an order has not been filled, the order self destructs at 3:50pm

2. an order has filled or partially filled, the trailing stop loss protects it and the closing trade is placed at 3:50 making sure that there are no open positions.

Is my code below correct?

def BracketOrder(self, parentOrderId:int, openinglimitPrice:float, quantity:Decimal, trailingPercent:float, timeswitch:str, adaptive_type:str):

    # 1st part: Buy Adaptive Algo order
    opening = Order()
    opening.orderId = parentOrderId
    opening.action = "BUY"
    opening.orderType = "LMT"
    opening.lmtPrice = openinglimitPrice
    opening.totalQuantity = abs(quantity)
    opening.transmit = False
    opening.tif = 'GTC'
    algo.FillAdaptiveParams(opening, adaptive_type)

    timeCondition = TimeCondition()
    timeCondition.time = timeswitch
    timeCondition.isMore = True
    opening.conditions.append(timeCondition)

    # 2nd part: Trailing Stop Sell order
    trailingStopLoss = Order()
    trailingStopLoss.orderId = opening.orderId + 1
    trailingStopLoss.action = "SELL"
    trailingStopLoss.trailingPercent = trailingPercent
    trailingStopLoss.orderType = "TRAIL"
    trailingStopLoss.totalQuantity = abs(quantity)
    trailingStopLoss.parentId = parentOrderId
    trailingStopLoss.tif = "GTC"
    trailingStopLoss.transmit = False

    # 3rd part: Sell Market order
    closing = Order()
    closing.orderId = opening.orderId + 2
    closing.action = "SELL"
    closing.orderType = "MKT"
    closing.totalQuantity = abs(quantity)
    closing.parentId = parentOrderId
    closing.tif = "GTC"
    closing.goodAfterTime = timeswitch
    closing.transmit = True
    closing.conditionsCancelOrder = False 

    timeCondition = TimeCondition()
    timeCondition.time = timeswitch
    timeCondition.isMore = True
    closing.conditions.append(timeCondition)

    bracketOrder = [opening, trailingStopLoss, closing]
    return bracketOrder

What makes you believe those fill prices are incorrect? I agree 10-15 ticks are unfavorable but not unheard of for orders and contracts worth $4,400 (MES) and $15,100 (MNQ). Depending on the market situation or trading time, market order fills can be significantly away from the last displayed ask/bid. Market order provides no price protection and may fill at a price far lower/higher than the current displayed bid/ask.

If you want more price control, consider LMT or STP LMT orders. The trade-off is, obviously, time-to-fill.

闯ü谤驳别苍

Hi All,

Adding to other observations. I recently opened real account with IB for India as an Individual. There is certainly some problem with some accounts.?

I am facing issues with Paper Account Trades not filling quickly (Even the market orders).?

Interestingly, I have worked with a client who has same account as mine and I placed same order at the same time on both accounts, mine and his.?
His account processes the orders in a correct manner while mine keeps waiting indefinitely.?

So, even if their algorithm of Paper Trading is same for same market/securities, there is something that is missed and that is causing the delays in order fills.

Hope anyone finds solution and posts here.?

Thanks and Regards,
Pratik Babhulkar

On Thu, Jun 22, 2023 at 01:29 PM, Lou Dudka wrote:

It'll take some work to upgrade my app from 9.17 to 10.19, but well worth it.

The deadline is looming... roughly three weeks I think. I just finished rolling my stuff out the other day.

On the bright side, it should take a couple of hours (max) to write a unit test in a virtual/paper-trading environment and confirm an update resolves that issue.

That's all I did, but since I've liberated myself from the MSFT eco-system, my help was of limited value. Sorry for that.

Good luck Lou.

On Wed, Jun 21, 2023 at 10:58 PM, Lou Dudka wrote:

You saved me some testing - THANKS!

You're welcome. BTW... thanks for replying to the list instead of a direct email. My manager was getting a bit ticked that I was fielding support out of band. They keep me on a short leash :-(

开云体育

I may get a little bit more of this 2105 than usual. But I must admit that I don't care about it because:
1- It looks like there is a new pattern about it, like not using the data farm for some time (minutes) will make it disconnected, but it get back live ~instantly on next request.
2- The explanation IB gave about the reason may no longer be fully applicable.
,{??? 2105,LOG_WARN??? ,ACT_RETRY,??? ??? "A historical data farm is disconnected.",??? "Indicates a connectivity problem to an IB server. Outside of the nightly IB server reset, this typically indicates an underlying ISP connectivity issue."??? }

If I have to guess I would say that IB did implement a "disconnect on lazy usage" in a recent revision. (maybe the latest one)

Anyway, on a 'sleeping connection', a reqHistoricalData1 Month of days Bars AAPL wake up all the system with a minor impact, as it is processed in about ~400ms instead of < ~50ms.
But once done the connection seems staying alive for a while.? Didn't tried extensively but I would say that during RTH you are good for ~10 min kept alive without new data request, aside RTH you are good for 3 min (seems to disconnect faster)

So you should not be worried because either you do infrequent request then 400ms first latency is probably not an issue for you, or you should not experience it at all if you have a heavy load.
Unless you experienced this error while doing frequent data request (I means at least one every 10 sec), The question for you is: does it happens while you are in middle of a heavy traffic ?

• Gordon pointed you to the documentation and as you can see from the heading for the 2xxx codes, they are warnings and not real errors.
• Some error message say something like "XYZ has become inactive". Those are the cases Gordon mentioned, where TWS/IBGW has disconnected a data farm that is currently not in use, but will transparently reconnect that farm as soon as you'd make a related request.
• Some error messages say something like "XYZ is disconnected". Those are cases, such as your code 2157, where TWS/IBGW connections got disconnected from the IBKR server that is mentioned in the error message. Shortly after that message you generally get an "all clear" message that indicates that the connection got reestablished.

Gordon is correct in that most of these "disconnect" events take place during the daily IBKR maintenance/reset window for your region and it takes only seconds (in fact often sub-seconds) for the "reconnected" message to come in. And if you have several accounts connected (such as a live and a paper trading account), each account will get the disconnect/reset at a different time within the daily reset window,

I suggest you do nothing special as long as your disconnects are brief and during the reset window. Restarting TWS/IBGW or your client will change nothing, will likely take much longer than the disconnect periods, and runs the risk of failing in case the connection is not back up yet. In case of 2157 you might just avoid making any requests that relate to instrument information (such as reqContractDetails, trading schedules, and similar) or be prepared to repeat the requests once the secdef farm is reconnected. But that should not be too hard, since you will likely make those calls when your client starts anyway.

• Your TWS/IBGW is connected to IBKR servers in a different region, data packets travel half around the world, and the natural higher packet loss rates causes brief outages. Just use the green "DATA" button in TWS/IBGW and check that they are connected locally.
• Your firewall/internet security software might interfere with certain packets, ports, or protocols used by TWS/IBGW
• A high packet loss rate or an unstable network hop between TWS/IBGW and IBKR may cause intermittent disconnects. If one of those legs is, for example, a Wifi connection, someone in your house with a craving for microwave popcorn might cause brief disconnects.
• Any equipment between TWS/IBGW and IBKR might have to renew a DHCP lease (your server, routers, switches, Wifi access points, internet modems). Disruptions will take place even if the renewal is instantaneous and the equipment's IP address does not change.
• Your ISP might reset/update the modem regularly and disconnect you entirely from the Internet during that time. Similarly, a piece of network equipment might get an automatic firmware or configuration update.

But chances are that your 2157 are brief during the reset window and you don;t have to do anything special.

闯ü谤驳别苍

Forgot to mention:
When I receive a 2000 class error, I keep pushing requests.
Otherwise said this is an informational message and while the code should be made aware that something happens, it should not be stopped querying,
Contrary to the implicit belief this could be for good.
My assumption is that in some circumstances, the Gateway go sleeping if such condition triggered and no new reason exist to re-establish the connection. Look at the message for error 2107. Not a clue just a suspicion but successful so far
TWS in itself is pretty active and have good reason to wake up IB connection to data farms, so it may hide that re-connection "on call" because you don't see TWS calling it.

Also you should ask yourself: when you got your 2157, how long was it after your last request for data to IB ?

IB designed the SDK ABI without special consideration to what we call "messages" (from them to us) , they are like "errors" (from them about us, understand bad behavior of our own code)
Do not consider everything that come through the error 'channel' as error. Even if it means something is not OK, it doesn't mean you can do something or that your code is culprit. (While generally this is the case)
They just inform you that there is reason your code doesn't behave as you expect and generally, they auto-fix it.

The 2157 you mention seems more frequent outside RTH (I suspect because they may do maintenance and reduce active farms),
There is nothing you can really do about it. It should? reconnect by itself a couple of second later and issue a 2158 Error code.
,{??? 2158,LOG_TRACE??? ,ACT_NOACTION,??? "Sec-def data farm connection is OK ",??? "A notification that connection to the Security definition data server is ok. This is a notification and not a true error condition, and is expected on first establishing connection ."}

? but 2157 doesn't seems a documented one

If very critical you can try the lengthy process of closing your connection and re-opening it. but before considering new dev, check first that after your 2157 you do receive (or not) an error-message 2158 in a timely manner that may suite you.

Sorry, the previous patch got malformed during copy & paste... assuming the groups.io preview function works, the one below should be used with instead.

--- makefile.~1~	2022-10-03 11:50:16.000000000 +0000
+++ makefile	2023-06-17 02:37:00.264457603 +0000
@@ -8,7 +8,7 @@
 TARGET=TestCppClient
 
 $(TARGET)Static:
-	$(CXX) $(CXXFLAGS) $(INCLUDES) $(BASE_SRC_DIR)/*.cpp ./*.cpp $(BASE_SRC_DIR)/lib/libbid.a -o$(TARGET)Static
+	$(CXX) $(CXXFLAGS) $(INCLUDES) $(BASE_SRC_DIR)/*.cpp ./*.cpp -lbidgcc000 -o$(TARGET)Static
 
 $(TARGET):
 	$(CXX) $(CXXFLAGS) $(INCLUDES) ./*.cpp $(BASE_SRC_DIR)/lib/libbid.so $(SHARED_LIB_DIRS)/$(SHARD_LIBS) -o$(TARGET)