TWS API Users Group

Re: Google Protocol Buffers usage in the latest Java API

rossh@... (rossh_yh) — Thu, 03 Apr 2025 22:43:59 -0700

It will take a while to convert over to this new API design. I think its a mistake to be doing this to a mature product that essentially has no new or important trading method additions pending any time soon.

But it does give me an opportunity to erase so much old code. By making the next release a 10.35++ only and forcing a cutoff point, I can eliminate hundreds of "if ServerVer > x" tests and plenty of "if ServerVer < 201" code too.

It would be nice to know how much of this API this ProtoBuf will eventually be applied too. Obviously this first version is just the starting point.

Re: TWS Time zone

fbell50@... (Frank Bell) — Thu, 03 Apr 2025 20:27:27 -0700

My problem is TWS is showing CDT after logon, even though it's configured to EDT in the "more options" screen available at logon. I have another Window's 11 computer that doesn't have this problem.

Re: Google Protocol Buffers usage in the latest Java API

pranav@... (Pranav Lal) — Thu, 03 Apr 2025 18:46:06 -0700

Hi Jürgen,

Many thanks. So, it appears we have some time but perhaps not to get third party frameworks up to date.

Pranav

Re: Google Protocol Buffers usage in the latest Java API

TwsApiOnGroupsIo@... (Jürgen Reinold) — Thu, 03 Apr 2025 18:25:46 -0700

Yes, Pranav. All TWS API clients that want to communicate with the capabilities of API 10.35.01 (server version 201) and higher will have to be able to send and receive protobuf formatted messages. IBKR has made those changes for all languages they support (including the IBKR Python API), but independently developed APIs including ib_async will have to add those capabilities eventually as well, or they are limited to requests, responses, and classes available in 10.34.02.

For the foreseeable future, clients that implement API 10.34.02 or below will still be able to communicate with TWS/IBGW 10.35 and above. That may be sufficient for many users for quite some time.

In API 10.35.01, IBKR has added protobuf formatted messages for the following items (though the original messages are still supported for clients with APs below 10.35):

one request: reqExecutions()
two responses: execDetails() and execDetailsEnd()
five classes: ComboLeg, Contract, DeltaNeutralContract, Execution, and ExecutionFilter

The classes and functionality of the request and the responses are identical to those in 10.34.02, except that ExecutionFilter in 10.35 has two new fields: the interger field "lastNDays" and the list "specificDates".

Jürgen

On Thu, Apr 3, 2025 at 07:20 PM, Pranav Lal wrote:

Re: TWS Time zone

dimsal.public@... (ds-avatar) — Thu, 03 Apr 2025 17:56:13 -0700

TWS switched mostly to canonical tz-database designations some time ago. America/New_York is in EDT, together with a few other US and non-US canonical regions from Canada and the Caribbean, so a any of these are equivalent to EDT.

Best,
DS

Re: Google Protocol Buffers usage in the latest Java API

pranav@... (Pranav Lal) — Thu, 03 Apr 2025 17:20:47 -0700

Hi Richard,

I see from the documentation that python is supported by protocol buffers. Does this mean that third party APIs like ib_async are impacted by this change?

Pranav

Re: Google Protocol Buffers usage in the latest Java API

rlking@... (Richard L King) — Thu, 03 Apr 2025 14:57:53 -0700

No, the ActiveX API is a wrapper around the C-Sharp API, and this change is internal to the C-Sharp API so it won’t look any different to the ActiveX code.

Richard

Re: Google Protocol Buffers usage in the latest Java API

joanmarcel@... (joanmarcel119) — Thu, 03 Apr 2025 14:31:22 -0700

What about the API implementations for Excel & vba? Are those affected?

Thank you

El jue, 3 abr 2025 a las 22:09, noreply.section+dev via groups.io (<noreply.section+dev=[email protected]" rel="nofollow noopener" target="_blank">[email protected]>) escribió:

Re: Google Protocol Buffers usage in the latest Java API

noreply.section+dev@... (lbilli) — Thu, 03 Apr 2025 13:09:34 -0700

On this topic, I also enquired with IB about some mechanism to opt-in/opt-out protobuf, possibly via a connection option or a TWS configuration setting, but they said no.

So, even though your client can still decide whether or not to use protobuf when sending a request, TWS responses will automatically use protobuf regardless, if API version �� MIN_SERVER_VER_PROTOBUF.

Re: Google Protocol Buffers usage in the latest Java API

rlking@... (Richard L King) — Thu, 03 Apr 2025 12:22:08 -0700

Ross

You’re absolutely right!

I was too lenient in my earlier post, because after a cursory glance a couple of weeks back I had mistakenly thought that the EClient.useProtoBuf() function was a settable attribute of EClient. But of course it’s not��

So it looks like I’m pretty much shafted by this. One of my API implementations is actually written in Visual Basic 6 (believe it or not, lots of history there) and is still a vital component in my trading platform, but there’s seems to be no chance of using protobuf in that. My other API implementation is .Net based, so there is a way forward there.

Oh well, life is full of surprises��

Richard

Re: Google Protocol Buffers usage in the latest Java API

rossh@... (rossh_yh) — Thu, 03 Apr 2025 09:55:46 -0700

I see in 10.35 in the C++, there is no option to ignore this ProtoBuf. 10.35 is version 201 (MIN_SERVER_VER_PROTOBUF), and its all coded into the source. It does not seem there is way to avoid this mistake. Looks like 10.34 will be the max build version for some time for many of us.

TWS Time zone

fbell50@... (Frank Bell) — Thu, 03 Apr 2025 07:34:28 -0700

I’m in the central time zone but I have my computers on EDT. When I run TWS on my new computer it displays CDT, not EDT. When I run it on any of my other computers it uses EDT. My new computer is setup for EDT and that’s what it shows in the task bar. Selecting “more options�� on the TWS login screen shows the time zone as ��(UTC-05:00) America/New York�� on the new and old computers.

Any ideas?

Frank

Re: Google Protocol Buffers usage in the latest Java API

rlking@... (Richard L King) — Thu, 03 Apr 2025 03:03:03 -0700

When use of Protocol Buffers was first suggested back in 2015, I posted
some comments on IBKR's GitHub repository that were fairly critical of
the idea. If you have access to the API repository, you can see these at:

https://github.com/InteractiveBrokers/tws-api/issues/2#issuecomment-141953319
https://github.com/InteractiveBrokers/tws-api/issues/2#issuecomment-340619917
https://github.com/InteractiveBrokers/tws-api/issues/2#issuecomment-340735285

(For those who don't have access, the attached file contains the text
from these posts.)

Most of what I wrote then is still true, but one thing that has changed
is that protobuf compilers now exist for many common languages: for
example WikiPedia says this:

"Protobuf 3.0 provides a code generator for C++, Java (including
JavaNano, a dialect intended for low-resource environments),
Kotlin, Python, Go, Ruby, Objective-C, C#, PHP, Dart.[14] It
also supports JavaScript since 3.0.0-beta-2.[15]

Third-party implementations are also available for Ballerina,
[16] C,[17][18] C++,[19] Dart, Elixir,[20][21] Erlang,[22]
Haskell,[23] JavaScript,[24] Julia,[25] Nim,[26] Perl, PHP, Prolog,
[27][28] R,[29] Rust,[30][31][32] Scala,[33] and Swift.[34]"

So those who develop their own API implementations using such
languages should have no trouble making use of IBKR's protobuf work.

Those who use other languages will be in serious trouble, unless IBKR
commits long-term to allowing use of either the old protocol or the
protobuf implementation. At present, the protobuf implementation
is very limited in scope, and use is optional. But presumably the long-term
goal is to extend the protobuf implementation to all API message types,
and who knows what IBKR will insist on then?

So my overall position is that this is all a big waste of IBKR's time and
effort, for no real benefit. If they were starting to develop the API now,
use of protobuf throughout would be a no-brainer, but after decades
of development using the current protocol I'd say: it ain't broke, so
don't fix it!

Richard

Google Protocol Buffers usage in the latest Java API

paulopersonal@... (Orionn) — Thu, 03 Apr 2025 00:58:48 -0700

Would anyone like to comment on the introduction of Google Protocol Buffers in the Latest Java TWS API version 10.35 ?

--
https://www.tradingsoftwarelab.com

Re: Anyone has code to show all option chain names for a symbol?

marluv@... (Marluv) — Mon, 31 Mar 2025 13:37:48 -0700

I think IB needs a callback to get OI. This is very slow and time consuming wow. IT should have been more of a spread sheet return.

Re: Late Prints don't show up when I call reqHistoricalTicks()

marluv@... (Marluv) — Mon, 31 Mar 2025 13:24:50 -0700

WORKED!! THANK YOU SIRRR!!

Re: reqContractDetails() does not get a callback if secType = "OPT"

Alex@... — Mon, 31 Mar 2025 08:41:09 -0700

Yep, you need to specify the option multiplier ("100").

You don't need to set conId = 0 unless you're reusing the same contract for the option as for the underlying; otherwise, I've noticed TWS will simply retrieve the contract associated to the conId if not 0.

Re: Improvements to Intraday Momentum Strategies Using Parameter Optimization and Different Exit Strategies

Alex@... — Mon, 31 Mar 2025 08:30:48 -0700

Thanks for sharing your research! I'll very interested to read it!

Re: Anyone has code to show all option chain names for a symbol?

Alex@... — Mon, 31 Mar 2025 08:26:40 -0700

Also, here's a list of the generic tick types in case you want to retrieve more data:
https://interactivebrokers.github.io/tws-api/tick_types.html

Re: Anyone has code to show all option chain names for a symbol?

Alex@... — Mon, 31 Mar 2025 08:14:39 -0700

You're welcome :)

Regarding Open Interest, I don't use it but found this (very old) thread that mentions the tick types you could set in your reqMktData() call:

/g/twsapi/topic/how_to_get_open_interest_in/4047032

Basically, it says that you should add generic tick 101 to the reqMktData() function:

m_pClient->reqMktData( ++m_requestId , retContract, "101" , false , false , NULL );

This should return a value in the tickSize() callback.

//! [ticksize]
void TraderClient::tickSize( TickerId tickerId, TickType field, Decimal size) {
//printf( "Tick Size. Ticker Id: %ld, Field: %d, Size: %s\n", tickerId, (int)field, decimalStringToDisplay(size).c_str());
}
//! [ticksize]

In the callback, just check the value of the field parameter and if it's field = 27, then the size parameter will be the call open interest, and if field = 28 then it will be the put open interest.