Timezones handling has been recently updated.

According to the , starting from 10.18, the time zone used by all timestamps sent by TWS can be one of:

• UTC
• Instrument timezone
• User timezone (i.e. the one selected at login)

Which of the three is used is set globally by the (slightly cryptically named) setting:

TWS -> Configuration -> API -> Settings -> "Send instrument-specific attributes for dual-mode API client in"

开云体育

You know, I still find this a bit strange since I can't find any mention of this 33 cent dividend on the investor relations site. Are there any Altria analysts out there that can fill me in? Is it buried in a press release somewhere? Is it a "secret" wildcard dividend or something, lol?

开云体育

A couple thoughts.

Sending +PACEAPI is not necessary any longer. For a while now, TWS/IBGW V10 throttle API requests by default and, in fact, you'd need to set option "Reject messages above maximum allowed message rate" in the Global API settings if you'd rather get error messages. +PACEAPI is now ignored (but should not hurt nor should it be the cause of your issue)

Is there any chance, one of your clients occasionally attempts a connection, establishes the TCP/IP socket, but does not attempt or complete the TWS API "welcome" phase of the protocol (the version negotiation)?

Take a look at Richard King's reply in post API client not able to connect to remote TWS instance . Richard nicely describes a condition that results in exactly the situation you experience.

We have also seen this in two different scenarios:

• We attempted to write a TWS Monitor that would regularly test whether TWS was running, was properly connected with IBKR, and that requests would receive responses within an expected time frame. Similar to what you are describing, this monitor created thousands of short lived TWS API connections per day (one at a time) and TWS would get stuck occasionally. In that case, TWS would still accept additional TCP/IP connections, but the TWS API protocol would never be established for those connections. TWS would still properly handle API conversations that had been established earlier.
• Our TWS/IBGW installation and most client programs are co-located in a remote server that is shielded from access via the internet (except for SSH). We occasionally connect some local tools to the remote TWS/IBGW through an ssh tunnel with port forwarding. Under certain circumstances (a combination of a Windows ssh implementation and interference by our ISP, a well known "Cable Company" playing games) TCP/IP connections could get into a zombie state where the remote TWS thought the connection was open (according to the DATA -> Connections window) but the local client was long gone. TWS would accept local and remote TCP/IP connections but the API welcome protocol phase did not take place so that the clients would be stuck. That is, until all zombie connections had expired after a long time.

If you still have tcpdumps handy (or next time you run network traces), look for a client TCP/IP connection that stays open for a while with no or incomplete TWS API welcome handshake (e.g. API version negotiation).

Hope that helps,

闯ü谤驳别苍

    from: 

    ...
    m_client.eConnect( ... )
    ...

    final EReader reader = new EReader(m_client, m_signal);   
    reader.start();

    new Thread(() -> {
        while (m_client.isConnected()) {
            m_signal.waitForSignal();
            try {
                reader.processMsgs();
            } catch (Exception e) {
                System.out.println("Exception: "+e.getMessage());
            }
        }
    }).start();

• EClientSocket::eConnect is only responsible for the socket, the connection request with TWS/IBGW, and the API version negotiation before actual API messages are exchanged.
• The client architecture has the option for eConnect to operate in an asynchronous fashion, meaning it does not block. The signal, in that case, is needed for the client to know when the connection has been established. For synchronous connection establishment, signal is only really needed within EClientSocket.
• Once the connection has been established, the separate reader thread makes a lot of sense but is, by no means, the only architectural option. But if it is used, it should check the connection status between processing messages.
• Our implementation uses two separate signal instances, one for the eConnect connection establishment and a different one for the reader thread.? We feel that is warranted since the signals are used during two very different phases of the API, EClientSocket/EClient keep their copy beyond just the eConnect, and things could get really ugly were EClientSocket/EClient to issue a signal during the regular message processing phase. Having said that, in the current implementation, sharing the same signal instance between EClientSocket::eConnect and the reader thread should work just fine and is most likely not the cause of the issue reported in the OP.

• ApiConnection --> The connection itself with EClientSocket and connect/disconnect operations
• ApiController --> The use of the connection such as processing requests, messages, and EWrapper callbacks
• It uses two different EReaderSignal instances one each and private to ApiConnection and ApiController respectively

• It looks to me that in the failure case (that occurs intermittently right after system startup) the clientSocket.eConnect call actually fails and the connection is not established. EClientSocket would indicate such a failure with an EWrapper::error callback and not with an exception

• Since the code that was presented starts the reader thread regardless of connection status, the immediate attempt to read from the closed socket will fail with an EOFException which leads the the Bad Message length error.

To get to the bottom of this, I'd intercept and log the exact exception in line 100 (aprox) of EClientSocket to understand why the creation of the socket or the connection sometimes fail.

闯ü谤驳别苍

You may speculate rightfully, but for reason I explained, as this could be eConnect launching it's own EReader using signal send to EClientSocket ctor
I guess your will need to step/step in eConnect to see what's happening after plain old? socket connect.
I don't believe that eConnect exits without connection up and ready.? eConnect contains very standard socket code. Oldies and Goldies connect.

Your attention should be raised by the fact that EClientSocket require "signal", that's not typical for a connection ABI to require a 'signal',
unless some synchronous mechanism exists, like using the signal for sync? recv decoding like maybe a? EReader sync that unwind in your eConnect. (as it does in mine)

Suggested code from IBKR are suggestion, doesn't means it's the best way to write production code, but easy to understand and learn how do design your implementation based on your own architectural design constraints.

In particular, it clear for me that a else clause is missing. If eConnect failed it's dangerous to persist and launch a Ereader, or even worst: starting a thread, while assuming that a non observable throw mechanism will bypass the eConnect failure by triggering the catch,? This is an abusive usage of a code safety mechanism.

When dealing with Bar, real time data are not real time, bcs you have to wait end of Bar anyway. (Slightly exaggerated as High and Low are updated even during Bar build time, as well as in Real time bar)

SMART seems to aggregate on "first come first registered" rules.
And Yes it seems that you get the aggregated volume from all supported exchanges (very many)
But I don't know any method to get where Bar data come from using SMART.
Conceptually the Bar API using SMART is not tailored for that as would need as many individual bars as there is exchanges involved,
This is feasible but have other drawbacks.
You can always call individual historical for specific exchange, even launching simultaneous request on a few of interest for you. But you'll quickly hit pacing violation.

Best solution is usage of "Ticks".
Better than Real time Bar. (which is not really as fast ans accurate as Ticks)

If you are ready to design code to listen to Ticks and to aggregate yourself the Bar, Ticks could fit your bill.
Because now you can know the exch from which each Ticks come from.
Dig Level1 doc (or even Level 2 market depth docs)? and setup proper Tick Kinds.
Ticks are more complex to handle but a very powerful data system from IBKR and very decently real time.

If only looking at SPY, and RT Bar are enough, and ready to look simultaneously at multiple exch, I suggest add ARCA to NYSE, that should cover enough
Or you will have to consider investing in Ticks handling

开云体育