Trading tools

Сотрудничество


 
Полезное
Подписка на RSS-ленту

Поддержать проект:

WM:
R757443857681
Z305778025977

Soft

28
Май

Plaza2 и МТС #3. Потоки

Потоки

Предыдущие посты под тэгом «Plaza2 и МТС» были посвящены введению в разработку МТС на Plaza2. Они представляли собой обзорный вью по устройству плазы и помочь начать разработку МТС для Plaza2. Начиная с этой публикации фокус будет смещен в сторону вопросов разработки МТС, по поводу которых (я надеюсь) можно будет подискутировать в комментариях.
Сегодня речь пойдет о потоках (threads), точнее о преимуществах и недостатках однопоточного клиента по сравнению с многопоточным. Согласно документации, существует возможность использовать клиента с несколькими потоками, и для этих целей реализовано 2 различные версии P2ClientGate.dll – для работы с STA либо MTA типами апартаменов при использовании COM-интерфейсов клиента шлюза. Рассмотрим, как может быть организован однопоточный и многопоточный клиент.

Однопоточный клиент:
Здесь всё просто, и, как мне кажется без вариантов: в одном потоке последовательно выполняется цикл, состоящий из следующих этапов:

  1. получение новых рыночных данных, состояний заявок, позиций по инструментам (выгребаем всё, что возможно вызовами ProcessMessage)
  2. расчет индикаторов, параметров рынка, торговых сигналов
  3. расчет новых цен заявок
  4. отправка транзакций на удаление, перемещение и выставление новых заявок

Пункты 2-4 должны исполняться максимально быстро. Любое промедление, любой лишний вложенный цикл, полный повторный перерасчетный цикл на каждой итерации вместо частичного перерасчета, где это возможно, или цикл с полным перебором для поиска, там где возможен индексный – всё это увеличивает время исполнения цикла и уменьшает эффективность работы торгового алгоритма.

Многопоточный клиент:
Каждый поток данных плазы получаем в отдельном программном потоке (thread), плюс один или несколько программных потоков на транзакции. Реакция торговой системы на события в виде транзакций возможна из любого потока при детектировании определенной рыночной ситуации (данные в одном из потоков плазы, например сделки), либо какие-то сложные триггеры.

Какую из моделей использовать лучше – предмет многочисленных дискуссий. Поделюсь своими соображениями на этот счет. Конечно, мои соображения не являются абсолютной истиной, могу где-то заблуждаться, но, по крайней мере, моя позиция будет абсолютно аргументирована.

Я однозначно за однопоточного клиента:

Во-первых, многопоточность – это зло, которое следует избегать во всех ситуациях, кроме тех, когда она объективно необходима. В основном случаи такой необходимости – это когда один поток может или должен работать независимо от других и результат его деятельности не влияет на ход выполнения остальных потоков. Например, при работе со шлюзом ASTS, транзакции можно отправить только синхронно и соединение будет заблокировано, до тех пор, пока не будет принят ответ на транзакцию. В этом случае необходимо отправить транзакцию в отдельном потоке через отдельное соединение, при этом получение и обработка рыночных данных происходит независимо. Бывают случаи, когда один поток не может не влиять на другой – это значит придется заниматься таким малоприятным занятием, как синхронизация потоков – это очень аккуратное программирование и отлов трудноуловимых багов.

Во-вторых, я не знаю ни одного убедительного аргумента в пользу многопоточности. Создание потоков не ускоряет работу процессора, не добавляет еще пару гигабайтов памяти и не ускоряет работу сетевого оборудования. Отправляемые и принимаемые данные уходят и приходят последовательно в любом случае.
Однопоточное приложение отлаживать гораздо проще. В отличии от многопоточного любую ситуацию можно отследить по последовательным сообщениям в одном файле событий. Однопоточный клиент позволяет удобно сохранять и воспроизводить рыночную ситуацию и (последовательную) реакцию торгового алгоритма на нее (бэктестинг).

А зачем объективно может быть нужен многопоточный клиент для плазы?

18
Апр

QuikOrdersDOM 2.0.4.7.

QuikOrdersDOM 2.0.4.7. доступен для скачивания в разделе “Скачать

Обновлены дистрибутивы QuikOrdersDOM и QuikOrdersDOM Box Setup

Внимание! Критические обновления! Рекомендуется обновить версию до последней.

Что нового в версии 2.0.4.7.
1) Исправлена критическая ошибка: в версии 2.0.4.7 могут некорректно работать модули автотрейдинга без ключей
2) Минимизированы внутренние задержки при работе с QuikOrdersDOM

06
Фев

Plaza2 и МТС #2

В протоколе Plaza2 применяется push-технология распространения данных. Это означает, что данные клиенту поступают по мере их возникновения, без запроса. Клиент определяет, какие данные он будет получать во время работы на первоначальном этапе согласования схемы обмена данными между клиентом и сервера Plaza2.

Топология, или что к чему подключается, описано в документе P2ClienGate.doc в разделе «Топология сети». Простыми словами схему подключения можно описать так: конечное клиентское приложение (робот) соединяется и обменивается данными с роутером по протоколу TCP, либо по протоколу LRPCQ на ваш выбор. Роутер соединяется и обменивается данными по протоколу TCP с инфраструктурой биржи. Роутер – это приложение Windows, которое также было установлено на ваш компьютер из дистрибутива вместе с библиотекой P2ClientGate, если в процессе установки были отмечены соответствующие опции. Роутер может быть установлен на той же машине, что и клиент, либо клиент и роутер могут находиться на разных машинах. Возможно 2 варианта установки роутера (опции в мастере установки): Роутер может быть установлен как служба Windows, либо как приложение. О протоколе LRPCQ в документации написано так:

LRPCQ является простым транспортом, основанным на использовании shared-memory в ОС Windows. Использование LRPCQ возможно только при запуске приложения-клиента и роутера на одном компьютере. Протокол LRPCQ имеет меньшие накладные расходы, чем TCP, передача сообщений между приложением и роутером с использованием LRPCQ будет происходить быстрее.

Файлы установленных модулей, включая настройки и log файлы, находятся в папке установки ( по умолчанию C:\Program Files\P2FORTSGate\ ).

Данные от сервера поступают в виде реплик. Реплика- это команда от сервера на изменение/добавление/удаление записей таблиц (заявок, сделок, и т.д). Таблицы сгруппированы в потоки репликационных данных.

На этапе согласования схемы репликации клиент сообщает, какие потоки данных требуются для получения, какие таблицы в потоках и какие поля в таблицах. Программно это осуществляется посредством набора COM-интерфейсов, описанных в документации. Клиент назначает набор функций обратного вызова для обработки реплик каждого необходимого потока данных. Поступающие от сервера реплики обрабатываются путем вызова одного из методов ProcessMesage ( либо ProcessMessage2 или ProcessMessage3) интерфейса IP2Connection. В зависимости от потоков данных и действиям, к которым относятся вновь пришедшие реплики, метод ProcessMessage последовательно вызывает зарегистрированные процедуры обратного вызова клиента, передавая в них параметры реплик. Метод ProcessMessage должен вызываться как можно чаще, иначе новые реплики накапливаются в очереди и очень быстро теряют свою актуальность с течением времени. Если у клиента накапливаются очереди в течении сессии, значит он теряет в своевременности получения рыночных данных из-за неэффективности реализации. Для контроля состояния очереди необходимо в файле P2SimpleReplClient_trace.ini в каталоге установки найти и установить в 1 (вместо точек) значение в строке «New message added to recvList. Size: %d=…» В ходе записи логов можно просматривать записи вида New message added to recvList. Size: xxx в файле лога P2ClientGate.log.

Транзакции (заявки на покупку/продажу, снятие, перемещение заявок) также организованы как методы интерфейсов. На каждую транзакцию от сервера приходит ответ в виде реплике с информацией об успешном или не успешном результате выполнения транзакции, причиной неудачи (если транзакция не выполнена), а также информацией, связанной с исполнением транзакции (например присвоенный номер заявки). Реализован метод асинхронной отправки транзакций, т.е. сообщение-транзакция отправлятся на сервер и код клиентского приложения продолжает исполняться без задержек на ожидание ответа от сервера. Когда ответ будет получен – он встанет в очередь вместе с остальными репликами и будет получен при следующем вызове функции ProcessMessage. Обработка ответов на транзакции осуществляется похожим механизмом, что и остальные реплики: при инициализации клиента регистрируется специальная функция обратного вызова, которая и будет вызвана из ProcessMessages для обработки ответов на транзакции

18
Янв

Plaza2 и МТС

Plaza2

Решил открыть новую рубрику “Plaza2 и МТС” на ttools.ru и написать серию постов на эту тему. Тема в последнее время очень популярна, и, надеюсь, найдет интерес. Речь о Plaza2 пойдет в контексте разработки фронт-систем алгоритмического трейдинга

Основные причины, по которым применение Plaza2 в торговых автоматах популярно (на мой взгляд) две: это относительное преимущество в скорости обработки транзакций и получения рыночных данных, а также повышение надежности за счет сокращения цепочки обмена данными от “биржа-сервер брокера-терминал клиента – торговый алгоритм клиента” до “биржа-торговый алгоритм клиента”
Читать полностью »

16
Янв

TradeProcessor 1.0.0.4.

Новая версия готова и доступна для скачивания в разделе Скачать

Trade Processor – программный модуль, который позволяет в автоматическом режиме управлять дельтой опционного портфеля, а также автоматически управлять размером позиции по биржевому инструменту, в зависимости от его цены

Что нового в версии 1.0.0.4:

  1. Продлен срок бесплатного использования до 1 апреля 2012 года.
  2. Внесены некоторые изменения в режим управления позицией по точкам. Введены новые настройки задачи:
    • Считать позицию по заявкам, а не по портфелю (позволяет вести несколько стратегий на один инструмент в одном портфеле);
    • Размер позиции (может задаваться перед началом работы, если позиция ненулевая; в процессе работы значение меняется в зависимости от операций, проводящихся по задаче).

    Подробнее про эти нововведения можно прочитать в полной инструкции

  3. Предусмотрена возможность работы с разными номерами счета одновременно.
  4. У каждой задачи появился параметр Title – заголовок, отображающийся в списке задач. Нужен для того, чтобы идентифицировать задачи по заголовку, даже если они работают с одинаковыми инструментами.
  5. В настройки [COMMON] в файле TPList.ini вынесен параметр ShowFormAtStart. Если установить его равным “1″ (ShowFormAtStart=1), то при запуске модуля автоматически появится на экране его форма.

Приятного использования и больших профитов! ;)

Скальперский привод для Quik QuikOrdersDOM

Подписаться на блог ttools.ru по email: