Why IB API echoes same order status multiple times?

C

Chronos.Phenomena

When my order are filled, I get more than one order state update trough order status method:

orderStatus(int orderId, String status, int filled, int remaining, double avgFillPrice, int permId, int parentId, double lastFillPrice, int clientId, String whyHeld)

Why is that?

It all happens in same second... fractions of second apart? why?


my thoughts...

if I have more than one instance of EWrapper... is IB API designed to push message to all instances... and not only connected one?
 
Quote from Chronos.Phenomena:

thanks for idea.. but it's not

I trade 1 lot futures contracts...
More...

That is completely normal.

You have to take it not as a "fill event", but more like a order "state polling".
For any state you can receive multiple events, with that state.

[Within automated systems one could just disregard the events following the last fill with unchanged positive "e.filled" ]

Tom
 
Quote from Chronos.Phenomena:

When my order are filled, I get more than one order state update trough order status method:

orderStatus(int orderId, String status, int filled, int remaining, double avgFillPrice, int permId, int parentId, double lastFillPrice, int clientId, String whyHeld)

Why is that?

It all happens in same second... fractions of second apart? why?


my thoughts...

if I have more than one instance of EWrapper... is IB API designed to push message to all instances... and not only connected one?
More...

Have you confirmed your last statement? That IB will send order fill information to multiple clients? I currently have a design such that separate strategies connect to TWS independently, but have not gotten to the point in development where I can tell whether IB TWS broadcasts this information to all connected clients all the time. Do you know for sure what the answer to this is?
 
Every client connects with unique id. Client with id=0 will get all mesages.
Relevant messages have client id in the structure so it is possible to process them accordingly.
As far as order status, do not have a hard proof, but it seems to me they are mimicking the FIX behaviour, which sends multiple order status messages (execution report, etc).

It is going to take me couple of more months, but when I am done with my Python IB client I will try to publish the code (most relevant parts) and some facts that I believe IB is miserably failing to document. Not at all do I claim the ultimate knowledge about their protocol, but I do hate with passion the client architecture. Can't do anything about that, so I am making my own (and still have to grind my teeth when dealing with their TCP client).
Anyway...
 
Quote from 6yaNYCjm5m:

Every client connects with unique id. Client with id=0 will get all mesages.
Relevant messages have client id in the structure so it is possible to process them accordingly.
As far as order status, do not have a hard proof, but it seems to me they are mimicking the FIX behaviour, which sends multiple order status messages (execution report, etc).

It is going to take me couple of more months, but when I am done with my Python IB client I will try to publish the code (most relevant parts) and some facts that I believe IB is miserably failing to document. Not at all do I claim the ultimate knowledge about their protocol, but I do hate with passion the client architecture. Can't do anything about that, so I am making my own (and still have to grind my teeth when dealing with their TCP client).
Anyway...
More...

IB's API is known to be so krappy... I just use a chart package and script it, the chart package developers have to deal with IB's garbage, not me... and the refuse to implement certain things just because IB makes it so difficult for them that they just won't go there... I wonder if OpenEcry is better?
 
Quote from maxpi:

IB's API is known to be so krappy... I just use a chart package and script it, the chart package developers have to deal with IB's garbage, not me... and the refuse to implement certain things just because IB makes it so difficult for them that they just won't go there... I wonder if OpenEcry is better?
More...

Some of it is not the way I would have done it, but it is reliable and robust which does count for quite a bit. The historical data portion of the API is a bit horrible and unnecessarily complicated to use. It is, however, perfectly possibly to make decent charts by using it.

Multiple status events reporting the same status should never be a problem. The operation is, in the jargon, idempotent. http://en.wikipedia.org/wiki/Idempotence#Computer_science_meaning
 
You must log in or register to reply here.
Back
Top