Досужие размышления о Quik, Lua и Python.

Я уже писал, что у меня сделана 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с, однако люди руками успешно скальпят и играют интрадей, и никого такие задержки не смущают. В любом случае, т.к. решение принимается в АТС на основе совокупности реал-тайм и внешних данных обработки, реакция системы будет лучше реакции человека.