|
PureBytes Links
Trading Reference Links
|
Jim,
I have looked at the server issue for a long time and my conclusions
were not very promising.
My specifications were:
1. Should store all symbols simultanously
2. Should provide real-time and historical data.
3. Should be accessible over a network
4. Should run on NT or Unix
5. Should have open interfaces
6. Should allow several data sources even home-brew
7. Should be able to cache symbols, which are not stored in realtime.
8. Should be cheap
This does not exist on the market.
The server market for small trading operations is small. However
numerous attempts have been made to produce servers for bank
enviroments. The most prominent propably beeing FAME which comes at
huge costs.
When we come to the low end we have there Townsend Analytics and the
UMDS which are open solutions. The Townsend servers run numerous
webservers like PCQuote, Reuters, SP comstock. This is because the
Townsend server is designed to run in a network. Furthermore it
provides authorization mechanisms for the data access. The Townsend
server can only be leased which is not so expensive.
The UMDS seems to be good in general but with the problems you
described.
If you are looking for an UNIX based solution then you can either use
standard SQL databases - however I doubt that they can handle huge
amounts of symbols. The other solution is to get one of the
"professional servers" and try to compile them on the Linux. I could
imagine that LMT-expo could provide you with such a solution.
However you will propably have to write the interfaces by yourself.
For a no-hassle-solution one should look seriously at townsend
because their servers are reliable, open, well documented and
relatively cheap. Furthermore I find NT to be quite stable as
long as one does not overload the machine.
Gerrit
> >>To that end, and to provoke a diversion from the Starr report, I'd
> >>invite a discussion of what we'd like to see in a real-time data
> >>server. Let's put together a software-engineering level product
> >>specification. I'll toss out some ideas of my own later. In the
> >>meantime, let's take Joe up on his challenge. What do YOU think
> >>should be in a real-time data server product spec?
> >>
> >>Jim
> >
> >For me, the specs of the UMDS are right on. Plus it's fast.
> >
> >And, most importantly, it's an open design. Multiple applications can use
> >it simultaneously. This is comparable to having an open computer bus where
> >you can use anyone's plug-in cards vs a closed proprietary one.
>
> Allan, can you point me to a copy of the spec for the UMDS?
> It does sound like one of the better starting points.
> I've heard something to the effect that current versions of
> UMDS have certain weaknesses in handling historical data,
> but that Kent is working to fix those weaknesses. I'd be
> able to comment more intelligently about that if I could read
> a real spec.
>
> I understand UMDS has three fatal weaknesses as far as I'm
> concerned:
>
> 1: It doesn't allow the importation of custom data into its
> realtime database. Same weakness as Omega's server. I've
> found a workaround for this problem in TS 3.5, but that
> workaround isn't practical for TS 4.0. Who knows about TS 5.0?
>
> 2: It doesn't work on any computer that's connected in any way
> to any network. This means I couldn't use it on my computer
> that's networked with my wife's computer, even though our
> activities are totally unrelated, except we share resources like
> printers, backup devices, etc.
>
> 3: It doesn't run on Linux. How can any software be considered
> "open" if it requires the use of a Microsoft product?
> Aside from the proprietary nature of the MS environment, I
> consider my trading workstation to be "mission critical" and no
> MS operating system meets that criterion.
>
> Jim
>
|