I have a suggestion, depending on the majority of users agreeing to
download the latest JDK 1.4 and provided there are no significant bugs
in the NIO (new I/O) API itself, we should ask IB to shift to JDK 1.4

I'm not really sure what you are asking, but it seems like you want to recommend to IB how they should implement their infrastructure.

I for one don't care if it's a bunch of squirrels running on wheels as long as it works. I don't see how it can work for the user base to tell the vendor how to implement the system.

Hello:

I have a suggestion, depending on the majority of users agreeing to
download the latest JDK 1.4 and provided there are no significant bugs
in the NIO (new I/O) API itself, we should ask IB to shift to JDK 1.4

There are lots of arguments that can be made against it, design changes
for one, but the main reason 'for' is scalability. Of course the speed
is mind boggling since much of the work is shifted to the underlying
OS. Let me try to put my thoughts across.

As you may know, a dedicated socket connection between each user ,and a
server at IB's end means a separate thread on their server, a machine
has thread limits, so I am dead sure that IB is forced to use a cluster
of UNIX mavhines. Superior performance can be achieved at IB's end if
there are lesser # of threads and reduced cluster. I am guessing that
there may be atleast 10,000 connections any given day, both retail and
institutional. I am curious to know actually how many machines are
servicing us.

THe New IO API, has selectors, which can service multiple clients in a
single thread, I just tested it all out at home, and well I can't do
much benchmarking but it struck me that once anybody gets it right, as
they claim it's non blocking and event driven, I am guessing it is like
the AWT/ Swing GUI behaviour and it will result in more reliable
service to us.

I had a hard time understanding the NIO API's, they are hard to
program, especially since I last wrote something about 8 months ago,
but I would like to see us migrate from a simple DataInputStream /
DataOutputStream with simple send()'s which is what is being used to
using a SocketChannel per client and selectors on IB's servers which
dont have to poll each client socket to see if data has arrived. Any
data comes from the client, and the selector is automatically notified
and there is much more efficient use of server resources.

Bottomline: we won't have that many problems. Which drives me nuts
sometimes. I am guessing that IB's systems are being taxed very heavily
now, and they are not scaling well due to the old design and old JDK.

I am sure some amongst us have thought about this, I sent a email to
Steve at IB (from management, I don't know if the Steve who answers
queries on their discussion forum is the same guy.) but he mislaid it.
This was maybe two months or so ago. I forgot all about it till this
email.

Please comment on this, and if we can drum up enough support, request
IB management to overhaul with a spanking new API alongwith the
redesign for the new programmer :)

grozzie! the NIO's are event driven just like AWT is, that much I can
recall. IB is simulating event driven behaviour but they can use a
standard Design pattern.

Please take a look at Doug Lea's excellent site, in general for thread
code and in particular for this brief overview in NIO...


Thanks

Message: 5
Date: Mon, 22 Jul 2002 19:16:08 -1000 (HST)
From: Richard Foulk <richard@...>
Subject: Re: API bugs, forwarding ...

I recently forwarded a message from this list to IB management in hopes
of eliciting a positive response. (I hope you don't mind, grozzie.)
I'm including the response below, which was somewhat positive.

I've omitted the authors name since I haven't asked permission to post
this ...

Hopefully good things come to he who waits ...


Richard

}
} Your points are valid. In the next month or so, we will be hiring a
programmer
} that will devote all of his or her time to the API, and at that time,

we will
} address your issues. Thank you for taking the time to write to us.
}
} Best Regards,
}
} [name omitted]
}
}
}
}
}
} Richard Foulk <richard@...> on 07/21/2002 08:28:30 PM
}
} To: ibmgmt/Interactivebrokers@Interactivebrokers,
help@...
} cc:
}
} Subject: API bugs, forwarding ...
}
}
}
} } Subject: twsapi: Event driven garbage
} } To: twsapi@...
} } Message-ID: <ahf2te+atl5@...>
} } From: "grozzie2" <grozzie2@...>
} } Date: Sun, 21 Jul 2002 19:43:42 -0000
} }
} } TWS is an event driven beast. No functions actually have any kind
of
} } return to validate they actually did something, everything waits
for
} } callbacks, to say events occurred.
} }
} } Event driven models are great, provided, the event source reports
the
} } events in the actual order they occur. TWS does not.
} }
} } If you are basing code on the events from the TWS activeX
component,
} } and building up logic for handling orders etc on it, be warned, I
} } have a captured log with the following sequence of events, and I'm
} } pondering what to do with it.
} }
} } The state begins with a short position of 20 contracts in the es
} } minis. The program has a target cover buy in place, and a stop,
for
} } 20 contracts each, and joined as a one cancels all group.
} }
} } Event 1 - TWS reports partial fill for 11 from target order
} } program modifies internal structures to show -9 left in the
} } position, with 11 bought.
} } Event 2 - TWS reports current position on ES as -9
} } program verifies this as correct.
} } Event 3 - TWS reports partial fill for 9 contracts, order filled
} } completely.
} } program modifies internal structures to show target order filled,
and
} } removed from the operating state.
} } Event 4 - TWS reports current position on ES as -9 contracts
} } program goes HUH ?????????
} } program realizes, all buy orders are filled, and it still has a
short
} } position of 9 contracts, places an order to buy 9 to cover.
} } Event 5 - TWS reports order to buy filled.
} } program modifies internal structures to show buy now filled, and
} } position back to 0
} } Event 6 - TWS reports position of 0
} } program verifies this is the correct position
} } Event 7 - TWS reports current position on ES as 9 contracts
} } program emits expletives into the debug log.
} }
} }
} } Computers are fast, and can react much faster than humans. What's
} } important to note in the above sequence, TWS reported a WRONG
} } position, and the program reacted. The position reported was
correct
} } for the time BEFORE the second fill report, and this is
significant,
} } because TWS reported the -9 position TWICE, once before, and once
} } after the fill for 9. It looks to me like the TWS internal state
on
} } actual position size got delayed, and would have 'caught up' had my
} } program waited longer before doing order/position reconciliation.
A
} } human cant react that fast, so if it displayed -9, and updated that
} } display to 0 a fraction of a second later, or even a couple seconds
} } later, a human would go 'great, filled'.
} }
} } 2 weeks ago, I realized, TWS events are not necessarily in
sequence,
} } and had settled on the position report event as the 'atomic' point
of
} } action, on the assumption, it would be the one event we could count
} } on to report things, and if we postponed all position management to
} } that event, everything would stay in synch. Up until now, it's
} } appeared that would work, but now i see it wont.
} }
} } I now have logs of various orders of events during the process to
} } prove, without any possibility of it being otherwise, there is no
TWS
} } event that you can rely on as an atomic thing, ie, it will be
} } correct. I have fills updated before positions, positions updated
} } before fills, and now i add to it, position reported late, or in
} } error. For now, i'll assume it was late, because if it was
actually
} } in error, and TWS was not going to follow the second -9 report with

a
} } 0 report, then it will not be possible to build a 'safe' program
} } using this.
} }
} } I can say the following with a certainty now. TWS is 2 or more
} } independant state machines internally, reporting events with no
} } relationships in time or order of events. If you are trying to
} } reconcile the events, and take actions based on the reports from
tws
} } in real time, at the time of events, then the following holds true.
} } If you are trading more than quantity 1, at some point in time, you
} } will recieve event notifications that will come in an order that
} } breaks your logic. I have drawn out carefully the timing diagrams
} } from a number of event sequences in the area of partial fills, both
} } on entry and on exit. The last one provides a proof, there is no
} } event from TWS that is atomic, on which you can base decisions to
} } manage existing positions, and reconcile with fill reports. The
TWS
} } position reports are independant of fill reports, and there will
} } ALWAYS be potential for discrepancies. The only way to do a
} } reconciliation, is to postpone it until a point in time that you
can
} } verify there are no potential outstanding events.
} }
} } It's time to re-design here.
} }

__________________________________________________
Do You Yahoo!?
Yahoo! Health - Feel better, live better

I second the fact that the demo account seems to come up in a random
state - active orders, already in positions, etc. This has never
happened with my real account.

Carl

--- In twsapi@y..., "grozzie2" <grozzie2@y...> wrote:

I have never had my live account start with an incorrect

portfolio.

I have seen the edemo account start up with some equity positions

but it

That's what I kind of expected to hear, that this is a 'demo' issue
only. Glad you 'sort of' confirmed that, because other than that,

we

are happy with current results, and I signed it off today for

limited

initial testing in the real world, not just the demo acct.

I have never had my live account start with an incorrect portfolio.

I have seen the edemo account start up with some equity positions

but it

That's what I kind of expected to hear, that this is a 'demo' issue
only. Glad you 'sort of' confirmed that, because other than that, we
are happy with current results, and I signed it off today for limited
initial testing in the real world, not just the demo acct.

开云体育

So now I'm wondering, has anybody ever seen TWS start up, and
initialize with wrong values in the portfolio, and then have them
stay wrong, using a real account ?

I have never had my live account start with an incorrect portfolio.

I have seen the edemo account start up with some equity positions but it almost always starts with no positions. I don't know if it changes its mind later on.

BTW, I don't know if you are using reqExecutions but it does strange things in the edemo account. I have had it return a bunch of executions that don't correspond to any orders I submitted. At least, I know I never used any of the Id's it reported.

Well, we just keep plugging away...

1. Manually check/correct open positions at startup (they a stored

in a

database and should be the same as yesterday evening)
2. Just track the status of orders while ignoring position messages
3. Using the status of the orders, update your own internal list of
positions
4. I compare my internat list of positions all the time with TWS

position

list. When it is different for more than 10 seconds, my software

I'm going to write this afternoon 'event' off to an artifact of using
cdemo for testing, and knowing, demo account behaves differently than
a real one, but, I thought you folks would find the following log
snips 'interesting'. I cant help it, I'm laffing from it.

To appreciate it, you must know a little about our 'design
philosphy'. An application such as this, has multiple sources of
data, and somewhere along the line, you have to decide, if/when there
is a discrepancy, one of them is right, and when it's programatically
impossible to tell which one is right, the program must choose one,
and proceed accordingly. So, in so much as 'what is current
position' for any given item, our choice is to believe what the
broker tells us. Over time, there are a number of reasons why, it's
possible for a position to 'change unexpectedly', one immediate
example would be a broken trade. If we have a prior trade broken,
then the position as reported by the broker will 'suddenly change'.
Another one of the philosophies is, all positions will have
protective stops in place, at all times. This is a simple 'capital
preservation' thing, in the event of "whatever", stops will be in
place, to provide limits on risk exposure.

So, after my 'escapades' on the weekend, I took the commentary of
some of the folks here, and went back to make some changes to basic
design of position management, to account for delayed updates etc
etc. Like you suggested, I now track what I think a position should
be (calculated from fills), and compare it to what is reported from
IB, and in the event of a discrepancy, I start a timer of
considerable length (1 minute), and 'do nothing' about it during that
time. If the positions come back into sync during that minute,
program is happy, and carries on it's merry way. At the end of a
minute, it will then sit back and apply the following logic.

I think a position should be X, but the broker has reported Y, and
it's staying that way. The broker knows better, there could be
factors that are outside the ability of a program to figure out, so,
if we are not back in sync after a minute, believe the broker, and
act accordingly.

So, a little bit ago, i started up TWS and logged into demo account.
That normally starts you off with no positions, and a liquidation
value of $50,000. I did a double take when the demo came up, and
immediately reported a position of 'long 1 nq'. No big deal, lets
just watch the things interact, and see what happens. Enter the
following log of events.

Got account time 16:52
Position NQ 1
Position reports 1 I think it should be 0 - Update postponed
Got account time 16:53
Delayed update, positions not in sync, correcting positions
No trade information available, using default values
Sending Initial Stop Order
PlaceOrder 69984 SELL STP 1 NQ 0.00 864.00
Order 69984 status PreSubmitted 0 filled 1 remaining
Got account time 16:54
Cancel Order
PlaceOrder 69986 SELL MKT 1 NQ 0.00 0.00
Order 69984 status Cancelled 0 filled 1 remaining
Order 69986 status Filled 1 filled 0 remaining price 881.00
Position NQ -1
Position reports -1 I think it should be 0 - Update postponed


To see what happened, I started the program up. It began with
position = 1 nq, abnormal, but, in a real valid account, would be
quite possible. The program sat there, and waited for a minute,
because it 'thought' the position should be flat, and was reported as
long 1. After a minute, the program goes 'broker knows best', and
places a stop order. Since this is not a system initiated setup, it
uses a default value of very wide 20 point stop. TWS reports the
stop. I'm watching and going 'ok, that worked fine, now i'm long
one, and stop is in place, but, I want to look at how it handles a
specific situation, so I need to get flat, and I instruct the program
to 'get flat'. It cancels the stop order and submits a new order to
sell 1 nq at the market. TWS reports the cancel, and the fill, and
then reports the position as -1.

This is the second time today I've seen cdemo account intialize, and
not have a 0 position on the NQ, but both times, after the first
execution, the position was reported back as if it had started at 0,
and just the first reported value was wrong.

So now I'm wondering, has anybody ever seen TWS start up, and
initialize with wrong values in the portfolio, and then have them
stay wrong, using a real account ? This is making me wonder a bit,
if the calculated and actual positions dont agree after a minute of
time to let them 'catch up', is maybe a better course of action to
pull the plug on TWS and restart it, rather than assume it's actually
reported correctly and act on it ? this one was definitely not a
time issue, or a case of 'its lagging', the times involved were
substantial, and nothing else was going on. It was simply a case of
a wrong value reported at startup, and the error was corrected, after
an execution took place that would update that value with a new
number.

Just as another FYI for the group, over the last 3 days, we have been
able to complete a full test plan, and only have one 'issue'
currently outstanding. Today, our isp had a lot of problems, and we
had many TWS disconnects. It was not always able to recover, and we
had to manually close and restart TWS itself today. It sure would be
nice if TWS would notify a client application that it's 'no longer
connected to ib'. I watched it once go thru the 'relogging' process,
and on attempt number 42, it got reconnected, and our program 'picked
up where it left off'. On 2 other attempts, after TWS finished
the 'relog' process, it was sitting there with a blank screen. It
accepted the connection and reconnects from client programs, but
there was no data, and no indication it was alive or dead. It's
pretty easy for a program to 'figure it out', but it sure would be
nice for a definitive acknowledgement to come from TWS. I guess the
next step is 'if tws appears dead, kill it and restart it'. Gonna be
interesting to define 'appears dead'.

hi,

yes this software I used to make this test application. What I would
like to know if someone has some example code that makes a link with
a real-time price. Possible the code in the TestJavaClient folder
incorporates this but it is not easy to find ....

rgds, Edward


--- In twsapi@y..., "skunktrader2001" <gdarke@b...> wrote:

--- In twsapi@y..., "ed2000nl" <empottasch@y...> wrote:

A small example code would be very helpfull and could enable me

to

link a Java program I am writing to the TWS.

A great place to start would be to look at the files in the
TestJavaClient folder.

Matt,

I remember you from RavenQuote and also glad to see
your posting.

Any idea when this integration be ready.

Thanks.

Suresh B. Ravanam

--- Matt Gundersen <mattgundersen@...> wrote:

Hi All,

I saw some talk about eSignal and IB. We are
currently adding IB support to
eSignal. You will be able to do direct/integrated
trading from within eSignal.
It will also be hooked into our formula engine
allowing formula/script
automated trading.

Matt Gundersen
Director Desktop Software, eSignal

__________________________________________________
Do You Yahoo!?
Yahoo! Health - Feel better, live better

__________________________________________________
Do You Yahoo!?
Yahoo! Health - Feel better, live better

--- In twsapi@y..., "ed2000nl" <empottasch@y...> wrote:

A small example code would be very helpfull and could enable me to
link a Java program I am writing to the TWS.

A great place to start would be to look at the files in the
TestJavaClient folder.

hi,

I wonder if there is some example code in JAVA to make a link with a
single or multiple cell(s) in the TWS. For instance to make a link
with the last price of e.g. CSCO or a range of last prices. This all
using the Java Client Socket. So I'm not interested in DDE actually.

I have found 5 Java files: Contract.java, EClientSocket.java,
Ereader.java, EWrapper.java and Order.java. Compiled it and put it in
a jar file. I am able to get the TestJavaClient working. However it
would be very nice if I could get some more info about how to get a
multiple link working between real-time prices of stocks or bid and
ask cells etc.

A small example code would be very helpfull and could enable me to
link a Java program I am writing to the TWS.

thanks in advance,

regards, edward

Matt

So thats where you went after leaving Raven...

Nice to hear from ya Matt....

No doubt Esignals getting their moneys worth...

Scott

--- In twsapi@y..., Matt Gundersen <mattgundersen@y...> wrote:

Hi All,

I saw some talk about eSignal and IB. We are currently adding IB

support to

eSignal. You will be able to do direct/integrated trading from

within eSignal.

It will also be hooked into our formula engine allowing

formula/script

automated trading.

Matt Gundersen
Director Desktop Software, eSignal

__________________________________________________
Do You Yahoo!?
Yahoo! Health - Feel better, live better

Hi All,

I saw some talk about eSignal and IB. We are currently adding IB support to
eSignal. You will be able to do direct/integrated trading from within eSignal.
It will also be hooked into our formula engine allowing formula/script
automated trading.

Matt Gundersen
Director Desktop Software, eSignal

__________________________________________________
Do You Yahoo!?
Yahoo! Health - Feel better, live better

Nick

In my previous post on this I suggested that an apology was in order, after
all you wrongly accused someone of a crime. Now you don't apologize and
want the evidence scrubbed. OK, we all understand more about you now....

Please also refrain from writing to me personally, I get enough of your
*** as it is.




Nick
<nickrbox@optonli To: twsapi@...
ne.net> cc:
Subject: RE: twsapi: Re: Order Entry System using IB (TWS)
24/07/02 01:57 and ESignal (WinRos)
Please respond to
twsapi






Croc Wrote:

So, I'm really only asking for something, which I could legally use,
without violating any contract I have with ESignal.

But please be a little bit more careful, if you call someone in a public
forum a thief, acusing him of stealing data, which he is entitled to
according to his agreement with the Provider

I will defer to your interpretation of the agreements and retract my
previous statements. I would also request that my previous posts on this
topic be deleted to avoid them appearing in future digests.

- Nick


Yahoo! Groups Sponsor



ADVERTISEMENT
(Embedded image moved to file: pic05436.gif)





To unsubscribe from this group, send an email to:
twsapi-unsubscribe@...



Your use of Yahoo! Groups is subject to the Yahoo! Terms of Service.

It probably means that they had one of their current programmers working on
it part-time and part-time wasn't cutting it.

Kent

} Your points are valid. In the next month or so, we will be hiring a programmer
} that will devote all of his or her time to the API, and at that time, we will
} address your issues. Thank you for taking the time to write to us.

Yikes! Does this mean they hired a high-school kid to do the current api?

Yes, I had a suspicion you were getting greedy. :-)

It's been a long hard road talking IB into supporting trailing stops.

Simple fixed-size trailing stops are a great advantage. And a great
start for greedy types too. :-)


Richard

} Richard,
}
} You missed my point.. "...based on each stock's volatility." My
} understanding is that IB's feature will only follow your price a
} fixed number of points.
}
} Of course you can use the API and set a trailing stop based on
} anything you like, which is what I do, but a fixed point stop misses
} the boat, in my opinion.
}
} In my ideal world trailing stops should be based on a selectable list
} of criteria... it's not like it would be difficult! IB is going in
} the right direction though, so I applaud them for finally seeing a
} little bit of the light :)
}
} Brian
}
}
} > Who said it wouldn't be adjustable?
} > Yikes! Silly assumption.
} > Richard
} >
} > }
} > } I would never use this... I actually can't imagine using a
} > trailing
} > } stop without basing it on each stock's volatility. I've been
} > } discouraged for years because no portfolio feature at the most
} > } popular financial websites offer any kind of adjustable trailing
} > stop
} > } alert... I mean c'mon, WE HAVE THE TECHNOLOGY! geeesh.
} > }
} > } ok, I got that off my chest lol :)
} > }
} > } > Trader Workstation Trailing Stop Orders and Island 1/10 Cent
} > Order
} > } > Entry
} > } > You asked for it, and IB delivers.

Richard,

You missed my point.. "...based on each stock's volatility." My
understanding is that IB's feature will only follow your price a
fixed number of points.

Of course you can use the API and set a trailing stop based on
anything you like, which is what I do, but a fixed point stop misses
the boat, in my opinion.

In my ideal world trailing stops should be based on a selectable list
of criteria... it's not like it would be difficult! IB is going in
the right direction though, so I applaud them for finally seeing a
little bit of the light :)

Brian

开云体育

-----Original Message-----
From: crocodile_1964 [mailto:crocodile_1964@...]
Sent: Monday, July 22, 2002 6:36 PM
To: twsapi@...
Subject: twsapi: Re: Order Entry System using IB (TWS) and ESignal (WinRos)

Hi,
it seems, no one is using the ESignal Datafeed together with IB. I
can only recommend it, as it's sometimes cheaper than QCharts. If you
talk directly with a sales representative, they might offer you
special discount rates. But what's even better, they normally don't
screw up with the datafeed in high volume times. Something you find
almost daily on QCharts.

I have uploaded an ESignal.zip file in the Files section, showing a
very basic implementation of a DDE-Lonk to WinRos.exe (the Datafeed
Manager), which needs to run prior to requesting the DDE-Link.
The Project provides some basic data, a Level I window and a Time of
Sales list.

Hope it helps someone to save time implementing the ESignal Datafeed
in a TWSAPI Aplication.

Good trading,

croc



> Hi members.
> Due to the timelag the QCharts Datafeed experiences especially the
first and last 30 minutes of trading, I'm considering using the
ESignal Datafeed for my Order Entry System.
> The ESignal Datafeed can be accessed through a DDE-call to
Winros.exe (The Datamanger from ESignal).
> Due to my only modest programming skills and since I've used 'till
today only Active-X applications I'm at
> a loss how to program the VB DDE-call to Winros, to get streaming
realtime data for select Futures.
> I don't need the exact calls to Winros, the general description of
a DDE call from VB would be sufficient.
> In Excel the call would be: =winros|key!symbol
> with key = Last, High, Low, Volume ...
> Perhaps someone could help.
> Thanks.
>
> croc



To unsubscribe from this group, send an email to:
twsapi-unsubscribe@...



Your use of Yahoo! Groups is subject to the .

To unsubscribe from this group, send an email to:
twsapi-unsubscribe@...



Your use of Yahoo! Groups is subject to the .

There are several big expensive brokers that do trailing stops on
the client, Cyber included.

Don't assume ...


Richard

} I wonder how long before the API supports this. Does the trailing
} stop sit on IB's servers, or is it implemented on the client?
}
} Scratch that last question... I am sure IB realizes how useless it
} would be to have this on the client.
}
} --- In twsapi@y..., "marinindextrader" <marinindextrader@y...> wrote:
} > Trader Workstation Trailing Stop Orders and Island 1/10 Cent Order
} > Entry
} >
} >
} > You asked for it, and IB delivers. As of August 1st, you will be
} able
} > to enter trailing stop orders with "Smart" order routing, and enter
} > 1/10 cent pricing for Island using Trader Workstation. Although
} > trailing stops have been introduced because of demand, IB does not
} > encourage the use of trailing stop orders as they create a false
} > sense of security, and accentuate volatility in rough markets. A
} new
} > version of TWS, revised User's Guide and updated release notes will
} > be posted just prior to implementation by August 1st.
}