闯ü谤驳别苍

I think what you’re missing here is that the ‘extra byte issue’ was never a problem for any of IBKR’s APIs, at any version, that use V100 protocol (and didn’t have DisableV1000 set).

?

This is because of the way they work. They split the incoming message stream into individual messages using the message length header, and these individual messages are queued. Each message is then eventually removed from the queue, and EDecoder parses it according to the expected structure. Once it has dealt with the expected last field, any remaining bytes are simply ignored, job done.

?

But if you have a pre-V100 API implementation, the only way the parser knows when it has got to the end of a message is that it has processed the relevant number of fields for that message, and the very next field is the message type for the next message. There is no possibility here of breaking the overall byte stream into individual messages first, because there is nothing to indicate where the breaks between messages are without actually parsing the whole lot. Note that if you set DisableV100 for a V100 implementation, then the individual messages are extracted in precisely this way by parsing the byte stream – see the readSingleMessage() function in EDecoder: so in this case it’s vulnerable to the extra byte problem.

?

So the only people who have had a problem with the extra byte are those using pre-V100 APIs, (ie API 971 or earlier) ?or using API 9.72 or later versions with DisableV100 explicitly turned off. This included me, Ross Hemingway, and the others who voiced their experience with the faulty version of TWS 10.30.

?

As far as 10.30.1o is concerned, it is simply indisputable that it still adds this extra byte to the open order message, as my example from earlier today showed. My example was produced with my own .Net API implementation, which I haven’t fixed yet for this issue (it doesn’t use the message length headers). But my COM-based implementation that has been enhanced to use the message length headers works perfectly.

?

So I repeat, anyone using one of the IBKR APIs from 9.72 onwards will have no problems ?with TWS 10.30.1o (at least, not from the extra byte issue). Just for completeness, I still have the installer for API 9.72 (and for other versions going right back to 2003). I installed it today and ran a test with it: the order went through fine and the open order and order status messages were processed without a problem.

?

Richard

?

?