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

--

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:





(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

开云体育

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.

开云体育

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

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".

闯ü谤驳别苍

?

开云体育