Skip to end of metadata
Go to start of metadata

You are viewing an old version of this page. View the current version.

Compare with Current View Page History

« Previous Version 15 Next »

Overview

Some configuration requires using of several sources of security definitions, e.g. ORDERS-LOG contains orders for both futures and options instruments. While working with ORDERS-LOG, MOEX Spectra Market Data Adapter should know security information for both security types. This article describes how to configure such option.

How to set up multiple Security Definition feeds using configuration file 

Adding new connection

MOEX could provide separate configuration files for different feeds.

The configuration file - configuration.xml could be extended with new connections if it requires.

For example, ORDERS-LOG connection can be integrated into an original configuration just by adding a new MarketDataGroup to configuration section:

configuration.xml
<configuration type="Test" label="Test System" marketId="MOEX">
<!-- ... -->
	<MarketDataGroup feedType="FUT-INFO" marketID="F" label="Futures defintion">
		<connections>
			<!-- FUT-INFO feeds -->
		</connections>
	</MarketDataGroup>



	<!-- New section with ORDERS-LOG connections -->
	<MarketDataGroup feedType="ORDERS-LOG" marketID="D" label="Full orders log">
		<connections>
            <!-- ORDERS-LOG feeds -->
		</connections>
	</MarketDataGroup>

</configuration>

Adding multiple Security Definition sources

MarketDataGroup may contain as many connections as it is required.

The following configuration block shows how to get two security definitions channels for ORDERS-LOG feed:

configuration.xml 
	<MarketDataGroup feedType="ORDERS-LOG" marketID="D" label="Full orders log">
		<connections>
			<connection>
				<type>Incremental</type>
				<protocol>UDP/IP</protocol>
				<src-ip>10.50.129.90</src-ip>
				<ip>239.192.70.40</ip>
				<port>40040</port>
				<feed>A</feed>
			</connection>
			<connection>
				<type>Incremental</type>
				<protocol>UDP/IP</protocol>
				<src-ip>10.50.129.90</src-ip>
				<ip>239.192.175.40</ip>
				<port>41040</port>
				<feed>B</feed>
			</connection>
			<connection>
				<type>Snapshot</type>
				<protocol>UDP/IP</protocol>
				<src-ip>10.50.129.90</src-ip>
				<ip>239.192.70.41</ip>
				<port>40041</port>
				<feed>A</feed>
			</connection>
			<connection>
				<type>Snapshot</type>
				<protocol>UDP/IP</protocol>
				<src-ip>10.50.129.90</src-ip>
				<ip>239.192.175.41</ip>
				<port>41041</port>
				<feed>B</feed>
			</connection>
			<connection>
				<type>Historical Replay</type>
				<protocol>TCP/IP</protocol>
				<ip>1.1.7.202</ip>
				<port>7207</port>
			</connection>

			<!-- Futures security defintion -->
			<connection>
				<type>Instrument Replay</type>
				<protocol>UDP/IP</protocol>
				<src-ip>10.50.129.90</src-ip>
				<ip>239.192.70.11</ip>
				<port>40011</port>
				<maxKbps>128</maxKbps>
				<feed>A</feed>
			</connection>
			<connection>
				<type>Instrument Replay</type>
				<protocol>UDP/IP</protocol>
				<src-ip>10.50.129.90</src-ip>
				<ip>239.192.175.11</ip>
				<port>41011</port>
				<maxKbps>128</maxKbps>
				<feed>B</feed>
			</connection>

			<!-- Options security defintion -->
			<connection>
				<type>Instrument Replay</type>
				<protocol>UDP/IP</protocol>
				<src-ip>10.50.129.90</src-ip>
				<ip>239.192.70.27</ip>
				<port>40027</port>
				<maxKbps>128</maxKbps>
				<feed>A</feed>
			</connection>
			<connection>
				<type>Instrument Replay</type>
				<protocol>UDP/IP</protocol>
				<src-ip>10.50.129.90</src-ip>
				<ip>239.192.175.27</ip>
				<port>41027</port>
				<maxKbps>128</maxKbps>
				<feed>B</feed>
			</connection>

			<!-- OTC Issues feed -->
			<connection>
				<type>Instrument Replay</type>
				<protocol>UDP/IP</protocol>
				<src-ip>10.50.129.90</src-ip>
				<ip>239.192.70.31</ip>
				<port>40031</port>
				<maxKbps>16</maxKbps>
				<feed>A</feed>
			</connection>
			<connection>
				<type>Instrument Replay</type>
				<protocol>UDP/IP</protocol>
				<src-ip>10.50.129.90</src-ip>
				<ip>239.192.175.31</ip>
				<port>41031</port>
				<maxKbps>16</maxKbps>
				<feed>B</feed>
			</connection>
		</connections>
	</MarketDataGroup>


How to set up multiple Security Definition feeds using the source code

Extra security definition feeds could be configured with Spectra::SpectraApplicationParams::customSecDefFeeds_ parameter:

Application.cpp
Spectra::SpectraApplicationParams params;   
params.customSecDefFeeds_[Spectra::SpectraDataChannel("D", "ORDERS-LOG")].push_back(Spectra::SpectraDataChannel("F", "FUT-INFO"));   
params.customSecDefFeeds_[Spectra::SpectraDataChannel("D", "ORDERS-LOG")].push_back(Spectra::SpectraDataChannel("O", "OPT-INFO"));   
params.customSecDefFeeds_[Spectra::SpectraDataChannel("D", "ORDERS-LOG")].push_back(Spectra::SpectraDataChannel("S", "SPOT-INFO"));
This approach may be used as an alternative of configuration file (configuration.xml) modification and allows keeping the original version of configuration files.






How to get MDEntryTime with nanosecond precision.

move to "How to" for MOEX Spectra MD Adapter 


MOEX Market Data Multicast FIX/FAST Platform uses custom UTCTimeOnly, UTCTimestamp format in the FAST messages.

Find more details in official documentation: http://ftp.moex.com/pub/FAST/Spectra e.g. http://ftp.moex.com/pub/FAST/Spectra/docs/spectra_fastgate_en.pdf

Example of handling time from MDEntryTime

Application.cpp 
void ConvertTimeToStr(System::u64 entry, std::string* strTime)
{
    static std::size_t const TIME_LENGTH = sizeof( "HHMMSSsssssssss" ) - 1;

    std::stringstream stream;
    stream << entry; // convert u64 to std::string.
    std::string time(stream.str());
    if (TIME_LENGTH > time.size())
        time.insert(0, TIME_LENGTH - time.size(), '0');

    strTime->assign(time, 0, 2); // HH
    strTime->append( ":");
    strTime->append(time, 2, 2); // MM
    strTime->append( ":");
    strTime->append(time, 4, 2); // SS
    strTime->append( ".");
    strTime->append(time, 6, 9); // sssssssss
}


bool InstrumentHandler::onIncrement( Spectra::SpectraSubscriptionItem const& subsItem, Engine::FIXMessage const* const* msgs, size_t incrementsCount )
{
	// ...
    for( ; i < incrementsCount; ++i ) {
	    const Engine::FIXGroup& gr = msgs[i].getAsGroup( FIXFields::NoMDEntries );
	    for( int j = 0; j < gr.size(); ++j ) {
		    const Engine::TagValue& entry = *gr.getEntry(j);
			std::string timeNs;
			if (entry.hasValue(FIXFields::MDEntryTime))
				ConvertTimeToStr(entry.getAsUInt64(FIXFields::MDEntryTime), &timeNs);
			// ..
		}
	}	
	// ...
}


How MOEX Spectra Market Data Adapter reacts on Sequence Reset message

move to How to use Spectra Application Listener callbacks and leave a link to it there: Steps to migrate from the version 1.3.2 of Spectra adapter to version 1.4.1

The new type of messages (a message 'Sequence Reset') was introduced in Spectra FAST protocol specification v 1.4.2. 

MOEX Spectra Market Data Adapter handles Sequence Reset message in the following way:

  1. A Sequence Reset message received in Incremental feed initiates recovery mechanism for all subscribed instruments. 
    In this case, MOEX Spectra Market Data Adapter fires Spectra::InstrumentListener::onRecoveryStarted() and Spectra::InstrumentListener::onBookReset() callbacks.

  2. Sequence filtering mechanism isn't applied to Sequence Reset messages. 
    Therefore, OnRecoveryStarted and OnBookReset callbacks would be fired for each sequence reset message and even more than once due to A-B arbitrage. 


  • No labels