 |
|
|
|
 |
|
| Products |
|
|
|
|
|
|
|
|
| DART |
|
|
|
|
|
|
|
|
|
|
|
Internet
Delivery
Platform
iDP |
|
|
|
 |
|
|
|
|
|
The Streaming Delay Server (SDS) is a high-quality Triarch/TSA service
which provides streaming delayed data to off-trading floor users
and customers on the Web and will significantly reduce your exchange
fee costs. SDS is fully compatible with Harco's flagship DART usage
analysis and reporting system. Customers can integrate both systems
to provide metering of all market data information delivered to
the web. The system is extensible and capable of delaying a wide
universe of instruments - 100,000 and more.
The following are just some business uses of the server:
|
 |
Provide streaming delayed
data to the Internet for delayed quote applications |
|
|
Provide streaming delayed
data to the Internet for delayed portfolio pricing applications |
|
|
Supply streaming delayed
data on the internal Triarch system to off-trading floor users
in order to reduce data costs |
The server differentiates between real-time and non real-time fields
for delay purposes: real-time fields are delayed and non real-time
fields are passed straight through. SDS gives you the ability to
supply information to your non-trading functions and greatly reduce
your exchange fees. Investment Banking, Research Analysts, back-office
personnel, Internet and end-of-day program-trading applications
still have access to data while the server seamlessly tracks complex
exchange delay rules. Every tick received is delivered.
The Streaming Delay Server:
|
|
Is in production today
at major global banks |
|
|
Is fully configurable for
multiple exchanges |
|
|
Can support up to 50,000
instruments per server |
|
|
Is scalable and redundant,
providing a seamless quote stream; The load may be evenly
distributed across multiple servers |
|
|
Is administered from the
Web |
|
|
Works with Reuters DACS™ |
|
|
Is plug-and-play. No modification
is required to the display applications |
SDS Logical Diagram
Explanation
|
1. |
The Streaming Delayed Server
appears as a new service on the client's Triarch network.
Multiple instances are started as a load-balanced service,
pre-seeded with a "non-preemptable" list of instruments, for
example S&P 500, GDAX, FTSE 100, and Nikkei 225 constituents |
|
2. |
A trader requests IBM.N
from the new Triarch service IDN_DELAYED. If not cached, IDN_DELAYED
requests IBM.N from IDN_SELECTFEED and begins cacheing the
real-time fields. The non real-time fields are published straight
through. If cached and fully delayed, the real-time fields
are played back from the tape, else empty (configurable) |
|
3. |
The delayed update stream
for IBM.N is played back by IDN_DELAYED from it's tape to
the trader |
|
4. |
When the last trader closes
down IBM.N, IDN_DELAYED continues to subscribe to the data
from IDN_SELECTFEED to maintain a "hot" delay tape. The real-time
cache feeding the tapes are subject to a least recently used
pruning algorithm |
|
5. |
The server is administered
via the Web from any browser running on a trusted administrative
machine. The trusted machines are pre-defined to the IDN_DELAYED
servers |
|
|
