SMART-LAB
Новый дизайн
Мы делаем деньги на бирже
Информация
buybackoff
QuikSharp - интерфейс Quik Lua полностью в .NET
- 21 декабря 2014, 07:21
- |
Представляю вашему вниманию библиотеку для работы с Quik из C#/F#/.NET — QuikSharp.
Последняя неделя показала, что мне нельзя торговать руками на такой волатильности, и заставила задуматься о более серьезном подходе к автоматизации. В итоге — пока нет доступа к Plaza, Fix и другим нормальным API — я набросал эту библиотеку.
Главная идея библиотеки — всё, что написано в руководстве к Луа работает из .NET без изменений интерфейса. Quik и Lua — недружественная территория по сравнению с .NET, хочется свести их использование к абсолютному минимуму.
Реализован и протестирован механизм обмена данными на основе TCP sockets. Ping/Pong roundtrip с Квиком занимает 190 микросекунд на моем компьютере. Также реализованы сервисные функции и несколько функций обратного вызова.
Установить библиотеку в свой .NET проект можно из NuGet. В проекте будет создана папка lua, из которой нужно запускать в Квике скрипт QuikSharp.lua.
Примеры использования находятся в юнит-тестах здесь.
Предлагаю всем заинтересованным присоединиться к дописыванию, тестированию и улучшению библиотеки. QuikSharp — открытое ПО свободное для личного некоммерческого использование и всегда таким останется. Я считаю, что еще никто никто не разаботал деньги на рынке за счет более хорошего соединения с Квиком (а не с биржей), но у многих есть проблемы с базовой автоматизацией Квика.
Цель — реализовать и оттестировать 100% из функционала QLUA из руководства. Если найдутся желающие помочь дописать эту библиотеку, пишите здесь а лучше на ГитХабе в Issues.
В коде все должно быть кристально понятно — как добавить новые функции и события. Я генерирую структуры данных (таблицы) из описания QLUA документации с помощью Эксель-файла в корне проекта. Все имена в структурах данных полностью соотвествуют документации QLUA. Пример структур данных из QLUA в этой папке, пример простейших функций в этом файле, пример событий (функций обратного вызова) — здесь. Эти примеры — шаблон для других функций.
Пользуйтесь на здоровье и следите за обновлениями на ГитХабе! (+ оставляйте отзывы и предложения)
Update (v.0.1.3):
Последняя неделя показала, что мне нельзя торговать руками на такой волатильности, и заставила задуматься о более серьезном подходе к автоматизации. В итоге — пока нет доступа к Plaza, Fix и другим нормальным API — я набросал эту библиотеку.
Главная идея библиотеки — всё, что написано в руководстве к Луа работает из .NET без изменений интерфейса. Quik и Lua — недружественная территория по сравнению с .NET, хочется свести их использование к абсолютному минимуму.
Реализован и протестирован механизм обмена данными на основе TCP sockets. Ping/Pong roundtrip с Квиком занимает 190 микросекунд на моем компьютере. Также реализованы сервисные функции и несколько функций обратного вызова.
Установить библиотеку в свой .NET проект можно из NuGet. В проекте будет создана папка lua, из которой нужно запускать в Квике скрипт QuikSharp.lua.
Примеры использования находятся в юнит-тестах здесь.
Предлагаю всем заинтересованным присоединиться к дописыванию, тестированию и улучшению библиотеки. QuikSharp — открытое ПО свободное для личного некоммерческого использование и всегда таким останется. Я считаю, что еще никто никто не разаботал деньги на рынке за счет более хорошего соединения с Квиком (а не с биржей), но у многих есть проблемы с базовой автоматизацией Квика.
Цель — реализовать и оттестировать 100% из функционала QLUA из руководства. Если найдутся желающие помочь дописать эту библиотеку, пишите здесь а лучше на ГитХабе в Issues.
В коде все должно быть кристально понятно — как добавить новые функции и события. Я генерирую структуры данных (таблицы) из описания QLUA документации с помощью Эксель-файла в корне проекта. Все имена в структурах данных полностью соотвествуют документации QLUA. Пример структур данных из QLUA в этой папке, пример простейших функций в этом файле, пример событий (функций обратного вызова) — здесь. Эти примеры — шаблон для других функций.
Пользуйтесь на здоровье и следите за обновлениями на ГитХабе! (+ оставляйте отзывы и предложения)
Update (v.0.1.3):
Немного подкрутил и время туда-обратно снизилось с 200 микро- до 60 микросекунд! :)
Добавил еще три простых функции и пару событий. Копипаст шаблона уверенно и легко работает для новых фукнций.
План:
1. Все функции обратного вызова
2. Функции взаимодействия скрипта Lua и Рабочего места QUIK (включая функции для работы со свечами)
3. Функции для заказа стакана (сделано)
...
Самым последним в планах — сделать Функции для работы с таблицами Рабочего места QUIK, так как это слишком специфично для Квика.
почему нет? — есть.
и что за дурь делать из говна конфету?
религия не позволяет?
Идея хорошая. С удовольствием забрал бы в свои проекты по готовности.
Но чесно, не совсем понял зачем тестировать инструкцию по скриптовому языку и переносить функционал ЛУА в .Net. Просто набить руку… Ну или я не так понял просто.
Для олд скул программистов нет нормального и бесплатного Api к Quik. Всё из костылей…
Если бы ты сделал хорошее Api, вроде SmartCom (без косяков только))), с простыми вызовами базовых функций свойственных для Api к бирже(а не какого-то непонятного скриптового языка) тебя бы на руках носили лет десять.
Вот описание Смарт Ком: www.itinvest.ru/software/smartcom/ как стандарт.
Да, и что такое GPL3 — можно будет в коммерческих проектах такую штуку применять или только за бесплатно всё должно быть?
>> Если бы ты сделал хорошее Api, вроде SmartCom
еше один фантазер.
ты реально не представляешь что ты говоришь.
Ещё один тупой троль, не понимающий о чём речь.
да. Посмотри мой блог, земеля.
Кусок кода лежал с прошлого года, «набить руку» тоже имело место :)
GPL требует публикации изменений, если изменения поставляются ползователям. Для частного использования нет ограничений.
Свободное из всего этого только SmartCom. Но каркас с архитектурой уже понятны хотябы.
Менюшка переключения соединения и мой привод:
Была тоже давно идея сделать открытое Api для подключения к куче бирж, но забросил эту идею давно. Да и на тот момент мало практики было.
Короче не теряйся. Open Source жив. ГовноКомментаторов не слушай.
Надо подумать, может вместе попробовать что-нить делать.
On-Line получение данных из Quik в Java и не только
для доступа к Lua используется named pipe
скорость на реальном счете
18 миллисекунд — подключение к Lua (createpipe), затем 1 миллисекунда на каждый запрос (получение свечей, статуса соединения с сервером, времени сервера, стакана по любому инструменту)
Код на github рабочий как Proof Of Concept, но я с тех пор внёс несколько изменений для улучшения стабильности. Как нибудь выложу и их тоже.
Код состоит из части на Lua (server) и Java. Вместо Java можно использовать C# или любой другой язык с доступом к WinAPI, в том чиcле через FFI прокси.
художника легко обидеть.
уж не знаю чем привязка к С# универсальнее и гибче.
а скрипт на Lua легко дописать.
не нашел у тебя в примерах получение свечей или стаканов. поэтому сложно оценить разницу.
если ты про то что к Soсket можно подключиться удалённо, то я специально сделал Named Pipe локальным. Паранойя, знаешь ли.
кстати я запушил только что последние изменения к себе.
по поводу гибкости — последним коммитом добавил получение немедленного слепка стакана.
до этого было ожидание, пока стакан изменится, чтобы получить свежую информацию, теперь два варианта.
всё для гибкости и универсальности.
больше не отвлекаю. пост плюсанул.
Добавил еще три простых функции и пару событий. Копипаст шаблона уверенно и легко работает для новых фукнций
Спасибо.
План (по QLUA.chm):
1. Все функции обратного вызова
2. Функции взаимодействия скрипта Lua и Рабочего места QUIK (включая функции для работы со свечами)
3. Функции для заказа стакана
...
Самым последним в планах — сделать Функции для работы с таблицами Рабочего места QUIK, так как это слишком специфично для Квика.
Можно ваш контакт скайп или маил в случае вопросов работы с интерфейсом?
Недавно сам тоже приступил к реализации своего проекта и очень понравился вариант от ПВМ, так как в моем проекте необходимо делать выгрузку данных ленты принтов с последующей ее обработкой и выводом на график в сам Quik. Pipe подошел в данном случае из-за универсальности обмена в обе стороны. Единственное прийдется переписать QAPI от ПВМ, так как на .NET у меня Pipe сервер, а скрипт для выгрузки и скрипт индикатора будут подсоединяться как клиенты.
Ваш вариант тоже интересен на будущее.
С уважением,
Sockets не менее универсальны для обмена данными в обе стороны (full duplex) и я как раз это использую. У меня реализован multiplexing — вызов функции со стороны C# не блокирует канал, а создает Task, в течение обработки которого по каналу можно послать новые сообщения и принять результаты для уже созданных Tasks. Балгодаря этому производительность повышается в 3 раза по сравнению с блокирующим request/response. 60 микросекунд в обе стороны — это практически предел для железа.
Console.WriteLine(«MultiPing takes msecs: » + sw.ElapsedMilliseconds);
а в посте пишешь про микросекунды (10^-3 и 10^-6)
что на самом деле в результатах-то? микро или милли?
BTW, выставление заявки, я позавчера наконец проверил точно, через Trans2Quik.dll занимает ОТ 57 миллисекунд. За это время она успевает дойти до биржи, зарегаться там и в программу приходит ответ. От отправки до ответа — 57 миллисекунд. (Сервер естественно не у брокера) Так что сильно ускоряться смысла нет, imho. Quik хорош для дней, часов, ну, мб минут, но на тиках надо уже брать что-то пошустрее, так что скорость важна постольку, поскольку.
Скорость важна в моем случае, чтобы полностью переместить процессинг данных из Квика в .NET. События типа AllTrade идут потоком и на каждое событие добавится 30 микросекунд в одну сторону + время на сериализацию. 57000 по сравнению с 60 — мне кажется можно не париться об этих 60 и даже о сериализации…
а так удачи, не обижайся. про микросекунды теперь понятно. мой вариант действительно однопоточный и однонаправленный. это его недостаток. если имеется большой массив клиентов и постоянный поток в обе стороны, то конечно лучше замерять среднее время и твой способ должен быть гораздо быстрее.
я не стал с этим заморачиваться по той причине, что не хотелось слишком сильно залезать в потоковую модель Quik Lua — как там происходит синхронизация данных, освобождение ресурсов и так далее. поэтому только 1 поток, 1 клиент.
сериализацией точно можно принебречь. если ты только не десяти КБ гонять собираешься
При наличии 4-х процессоров: 1 на info.exe, 1 на функцию main, 1 поделенный на GUI и функции обратного вызова, и 1 остается на .NET. В самый раз!
на каждого клиента нужен поток.
или там просто очереди на вход и выход и 1 поток клиента 1 сервера? если с очередями, то хорошо получится, но не сильно маштабируемо, т.е. скорость высокой не будет.
хотя некоторый выигрыш будет в двунаправленной неблокирующей обработке.
я может быть тоже про неё прочитаю, должно получиться и с pipe.
спасибо за наводку :)
Есть такой проект StackExchange.Redis — там сделано по примерно такому же принципу мультиплекса, и это самый быстрый клиент для.НЕТ. Используются Correlation Ids сообщений при отправке и при получении — мы отправляем сообщение и на время забываем о нем, а когда приходит ответ — по ИД находим кому его отправлять. Используя Tasks, нам не нужно много потоков, thread pool & TPL & async/await все делают за нас (сочувствую java прогерам, что у них нет этих ништяков :) )
Кстати я пока писал это понял, что есть логическая ошибка в коде — нужно обрабатывать полученное из Луа сообщение в новом Task, иначе мы не получаем новые сообщения пока ждем обработки полученного.
спасибо за наводку :)
Добавил спецификацию транзакции — самое сложное, что в этой библиотеке вообще есть. Класс с 71 полями. Эхо пустой транзакции со всеми полями занимает 225 микросекунд (включает сериализацию — сокет — десериализацию — сериализацию — сокет — десериализацию). Если игнорировать пустые поля, то снова прекрасные 75 микросекунд. Компьютеры шустры в наши дни!
Сейчас самое важное проверить функцию sendTransaction в боевом режиме.
Типа как S#, но мне она местами не очень нравится и она закрытая. Или типа OpenGamma.
Когда есть интерфейсы для портфеля, сделки, ордера, и т.д. И всё open source." buybackoff
Возможно есть смысл полюбопытсвовать здесь:
bitbucket.org/SazanProject
на библиотеку эту (исходники C# под SmartCom) наткнулся здесь на этом портале,
автор smart-lab.ru/my/SergeyEgorov/blog/all/
виде по использованию библиотеки
www.youtube.com/user/codetraidingsystem/playlists
Хотел попробовать использовать твою библиотеку для квика. Взял из нугета.
пытаюсь загрузить скрипт lua. Quik выдает ошибку
error loading module 'socket.core' from file '...\lua\clibs\socket\core.dll':
Не найден указанный модуль.
Библиотека по этому пути есть
Я тестирвоал на двух Квиках, но на одной машине — не могу удаленно сказать в чем дело. С загрузкой библиотек по относительному пути из Квика были проблемы, но все решилось используя функцию ЛуаКвика, которая выдает абсолютный путь к скрипту, от которого строится относительный. Меня смущают три точки, должно быть две. Это полное сообщение об ошибе, или обрезанное?
Dependency Walker, показал не найденую зависимость API-MS-WIN-SERVICE-PRIVATE-L1-1-1.DLL. я не знаю что это за библиотека
>>Это полное сообщение об ошибе, или обрезанное?
Это полное сообщение.
>>Вам или еще кому-то
Не мне :)
Уже неделю мучаюсь. С консольным проблем нет, а в WindowsForm
строка типа _quik = new Quik();
не отрабатывает.
Попытка отследить точку проблемы через отладчик, привела к исключению Esent (что-то типа: база данных должна быть дефрагментирована или удалена)
Глубже нифига понять не смог.
Познания в C# неглубокие. Может кто-нибудь подсказать как ПРАВИЛЬНО создать простейшее WindowsForm- приложение, чтобы эта библиотека в нем работала?
Но за идею спасибо, буду изучать.
Кстати, Вы были правы на счет того, что студия глючит с путями к пакетам. Ручное отключения связей с ними, и последующее их восстановление решило проблему желтых восклицательных знаков.
как хотя бы запустить тест ping?
Опыт в теме у меня небольшой, возможно что-то делаю нет. Не получается.
C...QuikSharp.csproj: error: пространством имен XML по умолчанию для этого проекта должно быть пространством имен MSBuild XML. Если проект создан в формате MSBuild 2003, добавьте xmlns=«schemas.microsoft.com/developer/msbuild/2003» в элемент <Project>. Если проект был создан в старом формате 1.0 или 1.2, преобразуйте его в формат MSBuild 2003. C:\Users\LOOD\Documents\Visual Studio 2015\Projects\QUIKSharp-master\src\QuikSharp\QuikSharp.csproj
После попытки сборки выдает около 200 ошибок. В основном — связанных с пространством имен.