开云体育

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

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

--

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

//! [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]

Glad that worked, Pranav, and thank you for sharing the solution.

You asked about files where you can read TWS/IBGW settings from. Each account folder under the TWS/IBGW installation folder (the random looking folder names with 40 lower case characters) contains a file called tws.xml (for TWS), ibg.xml (for IB Gateway), or both depending on what you used for login. Those files contain all configuration and layout information. There are also daily backup copies such as tws.Wed.xml.

Unfortunately, those files are encrypted and, in order to decrypt them, you'd have to log into TWS/IBGW:

• In TWS you'd go to "File" -> "Layout Settings" -> "Save Decrypted Settings As". A window will pop up that warns about the fact that the file may contain personal information. The window asks whether you want to continue and has a Yes (left) and No (right) button. In case you select Yes, a file selector window opens where you can select the folder and file names for the decrypted information.
• In IBGW you'd go to "File" -> "Gateway/Layout Settings" and a text window with the decrypted XML content comes up. The window has three buttons called (from left to right) "Copy to Clipboard"m "Export Settings", and "Close".

The XML documents are length and have sections for many different layout and operational settings. Among them sections for API "Settings", "Precautions", and "News Configuration".

I always wanted to make some tools to automate the monitoring and changing of TWS/IBGW configurations as well as TWS tabs so that I can guarantee consistency between multiple accounts. Reading and updating the XML files once decrypted is not that hard, but the decryption and recovery steps have to be done manually at this point (as far as i know).

闯ü谤驳别苍

?

?

?

开云体育