Financial Transmission Ways # 3: Plaza II Protocol
In addition to international standards and financial information transfer protocols such as FIX and FAST , which we described earlier, the so-called “native” financial data transfer protocols operate on the stock market. They are used to obtain the necessary information by both private traders and brokerage companies - such native protocols are more functional than the generally accepted standards (such as the same FIX) that attract brokers.
The exchanges of MICEX and RTS that existed in Russia, which now merged into the Moscow Exchange, also developed their own native protocols. Today we will talk about the Plaza II protocol project, which was created by RTS specialists.
')
Plaza II Infrastructure
For communication between the exchange trading system (it is called Spectra) and client software, the so-called Plaza II gateway is used - a special software that receives and sends data using the appropriate protocol. The gateway is installed on a computer that must have a connection to the corporate network of the exchange, and to the network where the user's client application is located.
As a rule, traders install their servers either directly into the data center of the exchange, or place them in the data centers of their brokers , which are connected to the exchange by dedicated communication channels - this allows you to save money (colocation in the exchange data center is expensive), while maintaining a high level of exchange rate data.
SPECTRA Plaza-2 gateway includes two software components:
- The P2MQRouter module, which establishes TCP connections to exchange servers, receives and sends messages in the Plaza II format, encrypts information sent by a participant, and decrypts information received from the exchange, as well as authenticates the participant in the exchange network.
- Library P2ClientGate, which third-party companies are just used to create software for working in the stock market.
The P2ClientGate library exists in two versions that support different COM streaming models: STA and MTA models.
In addition, the P2ClientGate library is available for 32-bit and 64-bit Windows systems (similarly for CGate).
The exchange has a special document , which describes in detail the requirements for hardware and software for the normal operation of applications. For example, if we need to save data to a disk, then the requirements will sound like this: 4 GB operating memory, SAS controller with write-back caching mode, at least 4 disks in RAID10, etc.).
Data transfer
The main method of data distribution on the Plaza II platform is replication - the data is transmitted by the server to the clients in the push mode (that is, the client does not explicitly request data changes). The data is translated as a sequence of changes in relational tables, that is, replication data streams.
The client software subscribes to the necessary data based on the name of the stream (at the stream level the rights to access specific data are also set).
A stream can be in several states, including receiving snapshots (history of data changes), online mode (updating data in real-time mode) and error mode (this means that for some reason the stream cannot be opened).
When opening a stream, the developer of a trading application can set its mode of operation, which is selected based on the goals pursued (receiving snapshots, receiving and updating data, or receiving only data from the current time).
Each replicable table has in its structure the first three fields of a fixed type i8, designed to provide a replication mechanism:
- replID - unique identifier of the entry in the table. When you insert a new record into the table, it is assigned an identifier.
- replRev - unique change number in the table. For any change in the table (insertion, editing, deleting a record), the affected record gets a replRev value equal to the maximum replRev in the table before the +1 change.
- replAct is a sign that the entry has been deleted. When a record is deleted on the server, the replAct field contains the value of its replID. If replAct = 0, the record is active (not deleted).
| Plaza Types II | String representation |
|---|---|
| i1, i2, i4, i8 | Signed whole |
| u1, u2, u4, u8 | Unsigned integer |
| d s | Signed fixed-point number of the form [sign] nnnn.mmmm |
| t | Date and time in the format YYYY / MM / DD HH: NN: SS.XXX |
| c | Character string with a zero at the end |
| a | One character string |
| f | Signed floating-point number of the form [sign] dddd.dddd |
After the implementation of data schema matching, the client application sends to the server the maximum values of the replRev fields for each table. The initial synchronization consists in the transfer of all data with checks (“revision”) by the server to the client, larger than those indicated by the client.
After the initial synchronization, the stream goes online (for all tables, the maximum client revolutions coincided with the maximum server revolutions).
This means that the data in the tables after receiving the StreamDataEnd notification and before receiving the next StreamDataBegin notification is consistent.
Data change notifications can arrive only in the interval between the StreamDataBegin and the StreamDataEnd and in this interval the data in the table are not consistent.
Presentation of information
All data passing through the Plaza II gateway is divided into several logical groups:
- Reference information - the schedule and status of trading sessions, directories of instruments, bonds, firms and customers;
- Trading information - aggregation of “glasses” (broadcast by several replication streams), general market indicators, order and transaction logs of the user (and the trading system);
- Information for recovery;
- Information on funds and limits;
- Clearing information - clearing settlement prices, variation margin, delivery reports, customer funds based on clearing results;
- Information about indices and rates - the current values of the RTS indices, the values of exchange rates;
- Auxiliary information flows - current volatility values and theoretical options prices, variation margin values.
In order to carry out operations in the markets operating on the Spectra trading system, the user’s system must receive on-line a schedule of sessions (session) and a tool directory (fut_sess_contents, opt_sess_contents).
Data streams
Consider the specific data streams of the Plaza II protocol. For example, the FORTS_FUTTRADE_REPL stream contains information on bids and futures transactions on the Moscow Exchange derivatives market (FORTS).
The stream data schema includes the tables:
- orders_log - application log;
- deal - deals log;
- multileg_orders_log - application log by bundles;
- multileg_deal - transaction log for bundles;
- heartbeat - service table of server hours;
- sys_events - table of events.
The orders_log table looks like this:
| Field | Type of | Description |
|---|---|---|
| replID | i8 | Replication subsystem service field |
| replRev | i8 | Replication subsystem service field |
| replAct | i8 | Replication subsystem service field |
| id_deal | i8 | Transaction number |
| sess_id | i4 | Session Id |
| isin_id | i4 | Unique numeric identifier of the instrument |
| price | d16.5 | Price |
| amount | i4 | Volume, number of instrument units |
| moment | t | Time of the transaction |
| code_sell | c7 | Seller Code |
| code_buy | c7 | Buyer Code |
| id_ord_sell | i8 | Seller’s Request Number |
| ext_id_sell | i4 | External number from the application of the seller |
| comment_sell | c20 | Comment from the seller’s application |
| trust_sell | i1 | Sign of remote control (trust management) from the seller’s application |
| status_sell | i4 | Status of the transaction by the seller |
| id_ord_buy | i8 | Buyer Application Number |
| ext_id_buy | i4 | External number from the application of the buyer |
| trust_buy | i1 | Sign of the trust (trust management) from the application of the buyer |
| status_buy | i4 | Status of the transaction by the buyer |
| pos | i4 | The number of positions on the instrument in the market after the transaction |
| nosystem | i1 | Sign of a non-system transaction |
| hedge_sell | i1 | Merchant hedge sign |
| hedge_buy | i1 | Sign of a hedge deal by the buyer |
| login_sell | c20 | Seller username |
| login_buy | c20 | Buyer User Login |
| code_rts_buy | c7 | Buyer RTS Code |
| code_rts_sell | c7 | Seller's RTS Code |
| free_sell | d26.2 | Seller transaction fee |
| free_buy | d26.2 | Buyer transaction fee |
| id_deal_multileg | i8 | Transaction number for the bundle |
There are other data streams:
- FORTS_FUTTRADE_REPL - futures: orders and transactions;
- FORTS_OPTTRADE_REPL - options: orders and deals;
- FORTS_ORDLOG_REPL - flow of anonymous requests;
- FORTS_DEALS_REPL - a stream of anonymous transactions;
- FORTS_FUTORDERBOOK_REPL - futures: cut of the glass;
- FORTS_OPTORDERBOOK_REPL - options: cut glass;
- FORTS_FUTCOMMON_REPL - futures: general information;
- FORTS_OPTCOMMON_REPL - options: general information.
Also, the client can subscribe to receive data from streams of aggregated glasses:
- FORTS_POS_REPL - position information;
- FORTS_PART_REPL - information about funds and limits;
- FORTS_FUTINFO_REPL - futures: reference and session information;
- FORTS_OPTINFO_REPL - options: reference and session information;
- FORTS_MISCINFO_REPL - additional reference information;
- RTS_INDEX_REPL - stock indices;
- RTS_INDEXLOG_REPL - history of index values;
- FORTS_VM_REPL - variation margin;
- FORTS_VOLAT_REPL - volatility;
- FORTS_INFO_REPL - additional reference information;
- FORTS_TNPENALTY_REPL - information about the charges for the transaction;
- MOEX_RATES_REPL - online currency exchange rates.
Each of these data streams has its own table schema, they are described in more detail in a special document for developers of trading software.
With the help of the Plaza II protocol, not only information is received, but also commands are transmitted for performing operations in the stock market. For example, adding an application is carried out using a special method (FutAddOrder), which is represented by a separate table (for the CGate library, the names of the tables may differ).
The table for the result of the action is as follows:
| Parameter name | Type of | Default value | Description |
|---|---|---|---|
| code | i4 | Return code | |
| message | c255 | Message text | |
| order_id | i8 | Application code in the system |
The success of the operation is described by code 0, any other value indicates an error. Similarly, the removal of the application or the movement of applications.
Work with Plaza II
With the help of the Plaza II protocol, it is possible to work in different ways with the stock exchange: for example, there is a viewing mode, which is used only to get data, but not to make transactions with securities. To work in the system in different modes, special logins of different types are used.
You can connect to trades using this native protocol through brokers whose systems are certified by the exchange (ITinvest is included in this list).
Other protocols
In addition to the Plaza II protocol, which was developed by employees of the RTS Exchange, there is a protocol for work created on the MICEX Stock Exchange (as mentioned above, these two sites later merged into the Moscow Exchange). ASTS Bridge (TEAP) bidirectional gateway is used to carry out trading operations and obtain stock exchange data on the foreign exchange and stock markets - it will be discussed in one of our following materials. In addition, we will talk about the protocol Simple Binary Encoding, which, to a certain extent, is the successor of the FIX case.
Today, thank you for your attention, we will be happy to answer questions in the comments.
PS If you notice a typo or mistake - write a personal message, and we will fix everything promptly.
Source: https://habr.com/ru/post/261709/
All Articles