TWS API

[Dmitry Shevkoplyas]

Hi all,

Just for your info:

I was trying to rebuild TWSServer (IB connector of the TradeLink) to the latest IB API and found a group (much more active then tradelink-free one:)  where people discuss lots of deep stuff on the TWS API topics. All of them have some sort of running solutions (imho mostely self-made stuff) and no one on the list is using tradelink (as far as no replies from the ones who does for > 7days).

Join the group if you want to be IB API guru some day : )

http://groups.yahoo.com/neo/groups/TWSAPI/info

See you there!

Here's a awesome post (copy-n-paste) from one of the guru Jan Boonen who created the whole wrapper for IB API C++ thing:

---------------------------------------------------------------------------------------------------------------------

from: Jan Boonen

to: TWSAPI

Hi all,

There seems to be some confusion about the TwsApiC++ library provided by me. Here some history and some explanation to take away this confusion.

But first:

1. TwsApiC++ is not an extra layer of complexity around the IB api. Just the opposite because it hides all the extra posix complexity 
2. TwsApiC++ reinstates the basic and only valuable interface for its user:
1. the eClient, (not EPosixClientSocket! that's implementation, not api)
2. the eWrapper,
3. the classes in the Shared directory such as Contract, Order etc,
4. all the values one has to know to fill in the eClient parameters, which are not very well documented and sometimes hard to find. Also, if you like, using TwsApiDefs.h defines these values and makes typos checked at compile time instead of (to late) runtime! It's use is optional
3. And as such: its name is very well valid and legitimate. Although, it was not chosen to for that reason, just one has to chose a name. But I am happy with it, and now even more!

In short, learning TwsApiC++ equals learning the non posix IB c++ api, and it is easier and less complex then the  EPosixClientSocket api which is an extension of the normal functional IB api, because it forces you to know how to program sockets.

Some history.

TwsApiC++ is around since 2007 and its first implementation was for the api version 9.1 and by then, its main purpose was to have an implementation that was portable and a more pure library: a library that did not depend on a gui (windows) to get the eWrapper methods called, and a library that could be used in a console program.

Other solutions did exist at that time, but most where and/or C oriented, and/or totally new implementations to parse the incoming datastream on the socket. Seeing though the many efforts the IB programmers put in the source code to be backwards compatible with the different TWS versions the API had to talk to,  I wasn't comfortable with these new implementation. Therefore, I chose to use the original sources as a basis and include them in the project without changing a single character: safety! To adhere as close as possible to the behaviour of the API wrapped in the Windows gui, an automatic reading of the socket by calling the eClient::checkMessages() was implemented. The current versions give you the choice.

In version 9.61 in 2009, the posix socket implementation was offered by IB.

Normally, the need for a library such as TwsApiC++ would end. But in fact sadly enough, and I think on request of some C++ client programmers, IB exposed the posix socket api in the new IB tws api. The result was a more complex api and one that was not backward compatible with the non posix api!

I was astonished. As an application programmer, I couldn't care less how the IB C++ api implementation would communicate with the TWS! Using sockets was an implementation choice of IB, not part of the interface. I also would expect the api promises the programmer a robust connection with TWS, one the programmer could rely on that everything was send and received. But no, the programmers using the posix api must

• use low level macro's such as FD_ZERO and FD_SET
• use the socket select() operating system call most C++ programmers,  even seasoned ones, will never ever use
• became responsable to handle the situation when not every data was send immediatelly to the TWS after an eClient method call! Yes really, the programmer must check for it when using the posix api, otherwise the request will not be send until the next call to eClient! Not very reliable.

I couldn't believe what I saw in the example posix C++ program in the TestPosixSocketClient directory. Conclusion: with the posix implementation, using the IB posix tws c++ api became even harder!

So the goal of the TwsApiC++ library shifted slightly: back to basics and offering a robust and solid library for the TWS C++ API programmers. And in my opinion, that's exactly what it is.

Robust:

• implementation is hidden from the user, but the user has everything to make full use of the IB api
• untrapped exceptions thrown from the users code during the eWrapped method executions are trapped and reported to the user. This protects the internal IB code from becoming unstable or getting the code into an endless loop because the data is offered again.
• having a seperate thread for calls to the eWrapper and eClient is no problem, all calls to eClient are a critical section to protect the EClientSocketBase::m_outBuffer

Easy to use:

• as stated in the beginning, only knowledge of the basic classes is needed, not more
• including the TwsApiC++ TwsApiL0.h file is sufficient to have access to all classes needed, evrything is available 
• possibility for a separate thread handling the incoming data and calling the eWrapper methods automatically
• possibility to use TwsApiDefs.h where all values are defined the programmer should know about to fill in the parameters and fields to make the correct request in the eClient. The values are then checked against typos at compile time, not runtime.

Solid:

• extra code to ensure all data is send to the TWS 
  
• when connecting or disconnecting, EWrapperL0::connectionOpened() and  EWrapperL0::connectionClosed() are garanteed to be called

Hope this helps to get rid of all the confusion existing about the TwsApiC++ library.

Nice greetings,

Jan Boonen

---In tws...@yahoogroups.com, <cmilo43@...> wrote:

IB offers various ways accessing API. I do not remember any voting on popularity but I suspect that Java and C++ are most popular and can be used on different platforms (important feature). C++ API is quite complex and created in very convoluted way for no reason. Base IB C++ example is using MFC and it may not be primary UI choice for many developers. There is Posix version that is more usable but still not easy to implement.  Java example was easier to implement for me than C++ but I am not familiar with Java so I cannot comment. Project management with C++ is most difficult. No wonder that .Net and C# are gaining on popularity because it is easier to manage such projects including UI part and multithreading and performance is very good. Using .Net (native .Net C# or through ActiveX) offers most programmer productivity gains. ActiveX is best suited to rapid development or API testing and performs quite well in many scenarios.

On Wed, Oct 30, 2013 at 7:53 PM, Kurt Bigler <k...@breathsense.com> wrote:
>> you are using TwsApiC++ which you don¹t' mention, but is only what a fraction
>> of people here use (even those who use C++).
> 
> Kurt,
> 
> Before I spend another half year of my life on tws api c++ learning curve,
> please suggest what the majority of respectful group users are using.
> Basically my question is WHAT and WHY :)

I think most group members who are using the TWS API through C++ are just
downloading what IB provides and using it directly.

Be sure you understand that "TwsApiC++" is a very specific thing created by
Jan Boonen, distinct from the C++ version of the TWS API. I have often
thought the name was a source of confusion, requiring repeated explanation.
But it is an additional "wrapper" around the C++ TWS API as provided by IB.
It has certain value added. In years past IB did not provide the posix
version of TWS API as provided today and it was necessary to use some
unusual solution to either use it on Windows without Microsoft's socket
implementation, or to use it on the Mac. I used it on the Mac and crafted
my own solution, but got stuck with that at one point and switched to
"TwsApiC++". Then as I recall IB released the posix version of the API and
I switched to using that directly because it eased my path for upgrading to
the latest TWS API. At that time also TwsApiC++ had certain problems that
have since been resolved.

So whereas once it was more critical to use TwsApiC++ for a Mac or
non-Microsoft-socket Windows implementation, it is now more optional. You
should look at it yourself to see whether the value added is useful to you.
There are (or at least were) differences in the threading organization. I
seem to recall that TwsApiC++ imposes the use of a separate reader thread,
similar to the Java implementation. (I ended up circumventing this by
buffering the results back to my main thread.) But it is a while since I've
used it and am not up to date. Sooner or later Jan will probably chime in
with updated information.

-Kurt

---In TWS...@yahoogroups.com, <tws...@yahoogroups.com> wrote:

On Wed, Oct 30, 2013 at 7:53 PM, Kurt Bigler <kkb@...> wrote:

you are using TwsApiC++ which you don’t' mention, but is only what a fraction of people here use (even those who use C++).

Kurt,

Before I spend another half year of my life on tws api c++ learning curve, please suggest what the majority of respectful group users are using.

Basically my question is WHAT and WHY :)

Thanks!

Dmitry Sh.

--
с ч.гл.ув.,
Дима Ш.

[wilhelmstroods]

Thanks for info.  New tradelink site almost ready.  Will have latest build removing the offending code that Dimitry found.  A few days from now will announce here. Thx

--
You received this message because you are subscribed to the Google Groups "TradeLink-Free" group.
To unsubscribe from this group and stop receiving emails from it, send an email to tradelink-fre...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.