Блог им. 3Qu
Я уже писал, что у меня сделана C++ DLL, которая получает данные из Lua и пишет их в БД SQLite. Уже писал также, что DLL под Lua делается на раз, и даже приводил коды и шаблон проекта простенькой C++ DLL. Посмотрело несколько тысяч, скачало, аж 12 человек, применят от силы двое. КПД постов, прямо скажем, оч низкий.)
В DLL реализована как связь с Lua, и будет реализована сама стратегия, вот только не решил какая из них. Повторять старые стратегии на новой для меня платформе Quik уже неинтересно, а новых моделей АТС отработано уже несколько. Все моделируется в Python. Часть стратегий не требует сложной математики, и могут быть легко перенесены непосредственно на С++. Другие непосредственно в DLL перенесены быть не могут, т.к. используют пакеты Python — всяческие регрессии и машинное обучение.
В общем, получилось, что DLL является шаблоном для любой стратегии. Все необходимые для АТС данные доступны АТС — реал-тайм данные поступают в DLL непосредственно из терминала, а необходимая история пишется DLL в БД SQLite и читается АТС из базы данных.
Ну, а пока конкретная стратегия не выбрана неплохо заняться реализацией связи АТС -> Python.
Самым очевидным и простейшим видом такой связи является файловый обмен — АТС пишет запрос в файл, Python обрабатывает данные и пишет ответ в другой файл, АТС этот файл читает и использует данные по назначению. Я этот подход уже неоднократно ранее использовал в своих системах, он хорош еще тем, что при переходе на другие виды обмена (Сокеты, MMF и пр.) практически ничего переделывать не надо. Надо только перенаправить запросы в другую функцию. Скорость при таком обмене составляет ~10ms на запрос.
Файловый обмен оч.неплох также для всячесих отладочных работ, т.к. впоследствии легко заменяется другими видами обмена.
Вторым, и одним из самых распространенных является обмен информацией через сокеты. В С++ для этого существуют готовые библиотеки -
Класс CSocket и Класс CAsyncSocket. В Python также имеется библиотека Socket. Есть и другие библиотеки создания сокетов в Python так что реализация связи проблем не представляет.
Возможна также реализация связи через Pipes (именованные каналы). Соответствующие библиотеки также имеются как в С++, так и в Python. Многими pipes применяются, широко применяются, и они просто реализуются, а плохи только тем, что мне этот способ связи не нравится.)
Ну, и еще один способ связи — это связь непосредственно через базу данных. Коли уж база данных уже имеется в системе, то почему бы не создать пару таблиц, в одну из которых писать строки запросов к Python, а во вторую строки ответов. Связь через БД несколько быстрее файлового обмена, время передачи-приема составляет ~5-7 ms. Если еще учесть, что в таблице данные уже структурированы и не нуждаются в преобразовании к формату принимающей или передающей программ, то это дает дополнительный выигрыш во времени.
Последний, и самый сложный способ связи с Python — это связь через Python C-API. Соединяем DLL c Python, и непосредственно из DLL вызываем функции Python.
Я не сторонник последнего способа. Мне кажется, что Python должен быть отдельным приложением работающим независимо, и асинхронно (независимо от DLL) обрабатывающий данные, и выдающий их по запросу из DLL или просто асинхронно отправлять туда уже готовые результаты. Тем более, что все реал-тайм данные Python может легко получать из базы данных.
Задачей непосредственно АТС во всех этих случаях является постобработка всех полученных данных и принятие решений, а от составных частей особого быстродействия не требуется — доли секунды, или даже несколько секунд особой роли для сделки продолжительностью даже в несколько минут не играют.
Кстати уж, время реакции человека на внешние факторы составляет примерно 2с. Даже если вы оч тренированы, то все равно это время составит 0.5-1с, однако люди руками успешно скальпят и играют интрадей, и никого такие задержки не смущают. В любом случае, т.к. решение принимается в АТС на основе совокупности реал-тайм и внешних данных обработки, реакция системы будет лучше реакции человека.
Если по аналогии, то скальпить с помощью Питон вполне реально. Именно, не на Питон, а с помощью Питон.
Скажем так, Питон обсчитывает нужную статистику — это медленно меняющийся процесс и не требует значительной скорости, а принятие решений и торговля на основе этой статистики и реал-тайм данных осуществляется уже быстрым процессом, на С++, например.
TCP/IP
HTTP
Причем HTTP часто отдают предпочтение, потому что он через брэндмауэры пролезает.
2. В Вашем случае, конечно, необходимо использовать
TCP/IP и далее по убыванию
Pipes
DataBase
3. Если Приложение на Python + Мachine Learning на VM в Облаке Google-a,
то HTTP,
TCP/IP может не пролезть, но попробовать можно.
4.
Технологии отладки ПО не должны использоваться как дополнительные факторы при выборе того или иного метода обмена данными,
а также влиять на выбор архитектуры и реализации бизнес логики Приложения.
Если у Вас это так. То значит, что в технологиях отладки что-то не так.
ПРЕКРАЩАЙТЕ ДЕБАЖИТЬ и ПИШИТЕ ТЕСТЫ.
5.
Не нужно лазить и менять что-то сто раз в написанном коде.
Написал код, тесты запустил, все ок, Далее в код не лезем.
Точка.
В этом Вам помогут Интерфейсы, Абстрактные модели, Dependency injection
Почитайте еще про SOLID
Желаю сделать правильный выбор и успехов в реализации задуманного
Что касается файлового обмена, то для отработки технологий обмена, когда еще ничего не определено и все меняется по ходу пьесы, это самое оно.
Кстати, менять ничего не надо, заменяешь один объект другим, и все дела.
Однако, решение еще не принято. Посмотрим.
md110 сбка inbox.ru. Согласен на любой ответ, лишь бы он был:) Спасибо.
https://habr.com/ru/post/499152/