Btw, searching around revealed where the same failed binutils assertion yielded a dangerous relocation and linker core dump. It certainly seems the problem is due to linking intermediate object files created with different binutils. I agree with the github comment that says:

This is not worth anyone's time. Just compile both sides for the same target triple and avoid the whole thing.

Fwiw, IDK why the IB SDK is distributing a pre-built library (either .a or .so). The only reason I can fathom is that they've modified the reference implementation but this strikes me as unlikely. Anyway...

This is not best practice as far as I know, C/C++ is not "write once run anywhere". IMHO they should include the source (but this would complicate the makefile a bit). Or they should instruct the user to use either... their own system packages or build the stuff from Intel.

Maybe they'll do this in the future but beware for now.

Yes, I just tried building the TestCppClient in a KVM running Ubuntu 23.04 w/ g++ 12.2.0 and was able to get ./TestCppClientStatic built successfully without any errors. I ran it and watched it complain that it couldn't connect to TWS/IBGW, but that's it. I didn't do any testing beyond that.

HOWEVER... I was getting the dreaded dangerous relocation: collect2: fatal error: ld terminated with signal 11 [Segmentation fault], core dumped error until I remembered this.

So... I needed to apt install libintelrdfpmath-dev and change the makefile to use -lbidgcc000 instead of the library IB provides (libbid).

For whatever reason, IB is distributing their own version of the big decimal library and apparently it's not compatible with the ld provided by lunar lobster. I don't know any more details and would love to hear from those who do.

Anyway, I understand the error you're getting isn't the exact same so all I can say is "works for me; partially". They both look like relocation errors though... perhaps you can run with this information.

All this aside, trying to stay so close to the bleeding edge may be asking for trouble. The reason IB distributes their own version of big decimal may actually effect things; perhaps they've patched it somehow. And, there could also be incompatibilities with lunar lobster (which is not an LTS, but interim release).

If you are comfortable playing with this kind of fire, be my guest... you're a braver (or perhaps more hardworking) developer than I. I'm not sure that it's wise though.

?袄冲(ツ)冲/?

Building sources unzipped from twsapi_macunix.1019.01.zip yields the following error:

:: make
g++ -pthread -Wall -Wno-switch -Wno-unused-function -std=c++11 -shared? -I. ./*.cpp lib/libbid.so -olibTwsSocketClient.so
/usr/bin/ld: lib/libbid.so:cygming-crtbeg:(.data+0x0): multiple definition of `__dso_handle'; /usr/lib/gcc/x86_64-linux-gnu/12/crtbeginS.o:(.data.rel.local+0x0): first defined here
/usr/bin/ld: libTwsSocketClient.so: unable to sort relocs - they are of an unknown size
collect2: error: ld returned 1 exit status
make: *** [makefile:9: libTwsSocketClient.so] Error 1

I'm building on ubuntu lunar lobster with g++ 12.2.0

Has anyone compiled the cppclient successfully?

Bill Rees

The scanner you describe is pretty basic and works just fine within our framework (based on the Java API) as well as with the two sample API clients IBKR ships with the API:

• The C# client IBSampleApp.exe for Windows
• The Java based client ApiDemo.jar that works on all operating systems

It takes about 500ms for TWS to send the first block of 20 results right after subscription, and subsequent updates get sent approximately every 30 seconds after that.

Why don't you try and get a "second opinion" from one of the demo clients. That way, you'd know whether the issue is with your TWS/IBGW or your own client.

闯ü谤驳别苍

{
? "numberOfRows" : 20,
? "instrument" : "STK",
? "locationCode" : "STK.US.MAJOR",
? "scanCode" : "MOST_ACTIVE_AVG_USD"
}

I did, but it behaves the same way during RTH as well.

We had several posts lately about conditions when TWS/IBGW disconnects a connection. Just use the search function in the online interface. One of the replies is this one: /g/twsapi/message/51267

You might want to take a quick look at the TWS/IBGW logs (they are very verbose and complex, so ignore most of it and just look for an error message at the time when the disconnect took place).

The big ones to look out for are:

• During API connection, don't send any requests until you have received the NextValidID callback. Under no circumstance use "sleep" calls but properly "wait" for the events to occur.
• During API connection, make sure you do not have two client with the same clientId. Yoiu can use the green "DATA" button in TWS and IBGW to check for any lingering connections. Depending on your network setup, sockets can linger for a while after the previous client with the same clientId exited.
• If you do historical market data requests, make sure you comply with the various maximum allowed request rates or TWS/IBGW may disconnect you.
• TWS/IBGW will likely restart once a day and your client will experience a disconnect.
• TWS/IBGW might just have died or was terminated by your server for some reason.

Happy hunting,
闯ü谤驳别苍

Hi,

When I was checking the logs of my algo that was running in paper trading account today, I noticed that at some point the .disconnect() of the EClient (Python)?was invoked around 09:50 PST, so outside a possible server restart window.
I checked my codebase, and the disconnect was not initiated by my implementation. Could somebody help me out, and let me know if, and in which situations TWS/TWS API would disconnect on me? I must admin I have not implemented any connection monitoring / auto reconnect mechanism so far, which?
is something I intend to tackle next.

Thank you!
Simon

tl;dr: My calls to reqScannerSubscription arrive at TWS fine, but no data or error is returned.

(Note: I am puzzled why this was originally rejected. I do not believe this to be a golang problem and I've already translated the very few implementation details to use the terms in the TWS API docs.)

Hello,

I'm trying to set up a simple scanner (MOST_ACTIVE_AVG_USD) via a golang implementation of the TWS API. Late last week, I briefly had a few successful scanners running; this week, I'm getting no response back.

I don't just mean "no data" -- I would expect a scannerDataEnd response in that case -- I mean, nothing at all comes back. No data, no scannerDataEnd, no error, nothing.

The request is certainly reaching TWS; the scanner can be cancelled perfectly fine, and sending an incorrect request (e.g., with a bad scan code) does provoke an error. Other requests can be handled while the scanner is sitting there.

I see this in the client log:
> 14:34:48:024 <- 22-4-20-STK-STK.US.MAJOR-MOST_ACTIVE_AVG_USD--------------0------

but then nothing afterwards.

Any suggestions about what might be going wrong? I'm grateful for any help, and happy to fill in any details I've missed.

C

Hi,

I was curious to see people’s experiences using BookMap’s API, for observing market liquidity in CME products, with the TWS Api in Java. Specifically, I am interesting in seeing anyone’s experience incorporating the MBO bundle from BookMap, using stop and iceberg orders, and submitting orders via TWS all in a Java project. To my knowledge, and from the communication I have had with their support team, BookMap only has an official Java API and an unofficial python one, which is why I am looking for Java. And of course TWS supports almost all languages I just thought it would be easier to use the same language together in one project. I know this is a TWS forum, but in my opinion the potential of the BookMap api is really uncanny. Would love to hear from someone who has implemented a version of the HistoricalDataListener interface in the BookMap Api, but with stop and iceberg orders. Does the MBO bundle come with an implementation upon purchase?

Thanks,
Brendan

I'm sending a market order parent bracket order. I set the take profit and stop loss to the last traded price right when i send the market parent order.?
As you can imagine, often I get some slippage on the market order. So my original take profit / stop loss distance from parent fill can vary.?
So i'd like to keep the take profit / stop loss a fixed amount from parent fill price.?

Is there a best practice way to do this??

I'd still wish to get filled using market order on the parent.?

I could send market order, then obtain fill price from executions then modify the bracket orders take profit and stop loss prices then indeed its set as a function of market fill price.

The limits for real time data subscriptions are driven by the "data lines" concept and are very different from and and not related to the "60 requests per 600" seconds limit for historical data downloads.

Subscription requests for real time data streams have to comply with the global API rate limit of 50 requests of any type per second, though. V10 versions of TWS/IBGW throttle your requests automatically at that level (though you can switch that off) while V9 versions will refuse requests above that rate with a "pacing violation" error.

There is no limit on the number of responses from TWSAPI for all your real-time subscriptions combined. You can find a little more detail in a recent post about message volume from data subscriptions.

You are correct in that all accounts are allowed to have at least "100 concurrent lines of real-time market data" unless the accounts have high balances (> $1Mio) generate a lot of commissions (>$800 per month), or purchase up to 10 booster packs which add 100 lines per pack for a maximum of 1,100 lines per account. You can find more detail at .

data, as you found correctly, is capped at 3 simultaneous subscription unless you have 400 or more market lines. At 400 lines or more it is one subscription per 100 data lines.

The documentation says in the first paragraph that "The maximum number of simultaneous tick-by-tick subscriptions allowed for a user is determined by the same formula used to calculate maximum number of market depth subscriptions ". At least V9 versions of TWS/IBGW did enforce the limit of three TickByTick subscriptions at 100 data lines, but we have seen that more recent V10 versions seem to relax that a little to five.

Also, the TickByTick data limits are applied to the number of instruments that you stream, not the number of actual streams. In other words we stream TickByTickLast, TickByTickBidAsk, and TickByTickMidPoint each for five different instruments for a total of 15 streams.

Each subscription counts as one data line, so you could have up to 100 simultaneously.

And one last thing. Real time data lines are shared between TWS and the API. The combined total cannot exceed your limit (say 100). But you will use only one data line for each instrument that TWS and your API client(s) subscribe to simultaneously.

Hope that helps,

闯ü谤驳别苍

开云体育

Can you show us the request and the message,

Only the market depth API ?mentions how the number of simultaneous L2 requests relate to the number of market data lines available to a user. What about the reqRealTimeBars - it mentions the limitation of the number of API requests (60 per 600 seconds) but doesn't tell how many market data lines each stream would use. Is it just 1, so 100 simultaneous symbols can be streamed if the user has 100 market data lines? Also what about reqHistoricalTicks ?and reqTickByTickData??? Do they also have only the API request throttling and 100 tickers can be streamed simultaneously? I was getting market data lines exceeded error with just 3 simultaneous streams however, when using? reqTickByTickData. But I can't find any documentation on the same. It appears from practice all of these API streaming requests only allow 3 simultaneous streams just like the L2 streaming, which is the only place that documents how many simultaneous streams are allowed for a given number of market data lines.

Not sure I understand your issue because I don't know what is "similar" in your entry and what you were expecting.

If this is the issue: date number you look at are "epoch" time. 1686237900? =? June 8, 2023 3:25:00 PM
If need help see

IB doesn't always use "YYYYMMDD" sequence on historical when requested timeframe below day, it then switch to epoch time.
Not sure there it's flagged
I detect that easily, for the next coming 13 years the first char is a 1,
anyway epoch is always 10 chars for next 200 years, if use sub-second resolution like in 1686237900.1234 , the '.' is the mark of it

I am more concerned by the "?" in your entry, this value are typical of buffer cookies and may flag that you are having a buffer read overrun or something alike.

similar values is seen in the log..

W90 1000 1993 1686237900 4287.7500 4286.2500 4288.2500 4286.0000 4286.972197048161 7724 ?1686238123 4286.25

Is this a kind of format or error somewhere?


Anything that forum member knows anything about?

I would like to place a buy order that will fill at the open if the open price (or open ask) is between a certain minimum and maximum.

The maximum is easy enough (I think) using a limit on open order.? Can this be successfully used with a price condition for the minimum?? Something like:

A couple scenarios come to mind when you get no callback during a client connection to TWS/API. Please make sure you implement/override all three? methods so that you get all possible error messages.

The first scenario is triggered in case your client sends API requests too early after the call to connect. Take a look at the chapter in the where it says:

Important: The callback is commonly used to indicate that the connection is completed and other messages can be sent from the API client to TWS. There is the possibility that function calls made prior to this time could be dropped by TWS.

In our experience, TWS/IBGW will not just drop calls they receive before? but will actually give up and close/disconnect the network connection which your client entirely. The various TWS API implementations show slightly different behavior when that happens:

• From a quick glance at the C# implementation it looks like you would get an callback via the function with signature "void error(Exception e)"
• The Java implementation, for example, will send a (misleading) error 502 via the "void error(int id, int errorCode, ...)" callback

So make sure you wait (under no circumstance sleep !) until is called before you send any API requests.

There is a second scenario where TWS/IBGW generally would simply close the connection instead of sending an error code or . That is when your client attempts to connect with the same clientId another client already uses. You would get the same error callback as in the first scenario (different ones in C# and Java).

This scenario? can happen even if the client that originally used that clientId has disconnected or is terminated. Depending on your network setup, the first client's socket might be "stuck" or lingering and TWS/IBGW will refuse connection requests with that clientId until the operating system completely closes the first client's socket. In TWS, you can click the green DATA button in the upper right corner and it shows you a list of all currently used clientIds.

In both cases, TWS/IBG has given up on the connection, the socket is closed, and calling clientSocket.reqIds(-1) will have no effect (and should actually fail). You would have to reconnect at that point.

As a matter of practice, our framework blocks the client during connect until both and callback have arrived. The arrival order of these callbacks is random, so that often comes well after and, at least when talking to TWS, after a series of message code 21xx informational error messages about the connection status of the various data farms. This approach has led to rock stable connection logic forus for? years.

Hope this helps,

闯ü谤驳别苍

On Tue, Jun 6, 2023 at 03:57 PM, A.R.SYD wrote:

Thank you for your response. I have used the error() method, specifically the error codes, to monitor the connection status between my C# App and TWS. In the case where the connection is established between my App and TWS, but the NextValidID callback is not called, I am unsure whether I should proceed with calling clientSocket.reqIds(-1) or attempt to reconnect? Note that my App connects to IB without any issues most of the time, there are occasional problems with the connection, such as the NextValidID callback not being triggered.

Note: I am using a paper trading account, and I run My App and IB as Administrator

Your client application would have to implement/override the function, Robert. TWS API calls that function to report errors and the default implementation might simply print error messages.

In your implementation of you would match the id parameter of the function call with an orderId (or if the error is not related to orders, the id of another request) and parameter errorCode indicates the kind of error, a value of 110 in your case. A list of (most) error, warning, and informational codes you might get can be found in the section of the TWS API Guide.

闯ü谤驳别苍

I had not even realized that since the point you were making (as in IBC cannot help with IBKR maintenance windows or network issues between TWS/IBGW and IBKR) is valid for all servers. Those that relate to market data, historical data, security definitions, and those used for accounts, orders, and trades.

闯ü谤驳别苍

PS. I also realised that spelling the word "realized" still does not come natural to me after all these years. But people around me get really confused when I call the last character in the alphabet "zet" and use "s" instead of "z" in common words. I guess resistance, in this case, is futile.

On Wed, Jun 7, 2023 at 03:10 AM, Richard L King wrote: