Nikolay (Все сообщения пользователя)

Т.к. в примере присутствует OnAllTrade и у Вас организована подписка на поток сделок, скажем, по многим инструментам, то он будет постоянно блокировать поток для внесения новых данных.
Лучше удалить этот колбек. Либо добавляйте print debug сообщения, для оценки происходящего.

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

То что время серверной части не связано с временем биржи - это понятно. А вот если есть сильная рассинхронизация, то это повод что-то сделать.

Вопрос был не про синхронизацию. По факту вопрос был: контролирует ли серверная часть, поток данных от биржи.
Данная проблема решилась, когда брокер разорвал соединение (по крайнее мере терминал разорвал соединение самостоятельно) и после восстановления соединения время было синхронно.

И проблема явно была не в задержках, иначе бы данные приходили с задержкой. Они же приходили корректно.

Ищите сериализация данных lua и сразу найдете. На этом форуме была не одна тема с таким вопросом и даже примеры кода.

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

Я  могу понять, что это проблема брокера (Сбербанк), но с какой стати  время сделки в будущем относительно времени сервера брокера и времени  пакета?
Т.е. я понимаю, что время сделки просто транслирует биржа, но  серверная часть должна же не просто транслировать, но и как-то  контролировать, что она транслирует.

Если не прошла транзакция, оправленная командой самого терминала, то это уже не проблема клиента, если говорите, что данные обновлялись и торговая сессия шла. Я бы брокеру Алфьа не стал так уж доверять.

В данном случае, я тоже не очень понимаю смысл этого анализа, т.к. за время цикла задержки потока стакан изменится много раз. И это если анализировать всего один, не то что тысячи.
Можно догадываться, какая задача решается, но часто пытаются через стакан посчитать сумму заявок. Хотя это берется из ТТТ одной строкой. При этом, анализируя стакан, также стоит учитывать, что через Квик доступна только малая часть глубины стакана - в лучшем случае 50 строк, а чаще всего 20.

Но обсуждали чисто техническую реализацию, поэтому все это лирика.

Ну так Вы выполняете Unsubscribe_Level_II_Quotes один раз. Если она вернула false, то можете ее вызывать в цикле еще раз (но не бесконечно), пока она не вернет истину.
Это Вам выше и написали.

Это почему она не выполнима...

Решается она в виде очереди обработки, раз скорость не так важна. Оставим в стороне вопрос самого этого анализа.

Создаете очередь задач. Очередь - массив. Задача - объект, содержащий методы подписки, анализа отписки.
Далее в цикле начинаете обрабатывать, например по 10 за раз. Если в какой-то момент не происходит подписка, то просто переключаетесь на следующую еще не выполненную задачу. И так пока очередь не опустеет.
Можете обрабатывать простым циклом, можете корутинами - как угодно.

В книге автора языка есть хороший пример по скачиванию файла из интернета кусками. Это, по сути, та же задача.

Получить можно и без рисования. Но как показывает практика, часто данные не транслируются вовсе или с перебоями. Возможно зависит от брокера, у одного работает, у другого нет.

Предположу, что Вы хотите получить данные из Таблицы текущих торгов, т.к. не описываете какую задачу решаете.
Если так, то это не стоит делать через CreateDataSource.
Проще и быстрее это сделать через функцию getParamEx  http://luaq.ru/getParamEx.html

А CreateDataSource используйте если необходимо "упаковать" данные в свечи, бары.

Для срочного рынка и для фондового рынка используются разные счета.
Если Вы указываете класс фондовой секции TQBR, то и ACCOUNT укажите для нее.Он вряд ли будет начинаться с SPBFUT, т.к. это явно срочный рынок.

Нет, математики их не заменят. Но когда программист не знает элементарную математику, это гораздо хуже, если он не знает Git. Тем более, что сейчас Git, Docker, Cuber. А через несколько лет скажут что так не модно. Одно то, что сейчас почему-то все решили, что приложение - это браузер и больше ничего не надо, уже вызывает отторжение.

Сюр. Потому как есть алгоритмист, который пишет код, выполняющий то, что могу понять несколько людей на планете. Кто проверять то будет?

Если же речь, про "показать котиков", то да. Надо проверять. Но как показывает практика, проверяют не то. Цепляются за форматирование  и нарушение "святого" SOLID, а безопасность остается дырявой. Почему, а потому что, опять же, специалистов мало.

Справедливости ради, знание современных систем хранения версий - это ни в коем времени не характеризует кого-то как программиста.
Я когда начинал, мы учились на бумаге. В первую очередь просто алгоритмы. Потом код на бумаге. И ничего, абстрактное мышление хорошо развивает.
То что сейчас без знаний Git не считают кого-то полноценным программистом, то это сюр, т.к. это знание ничего не дает.

И это удобно, красиво и т.д.

Мне нужен таймер в одной функции, в другой, в третьей и т.д.

Шаблон создания таймера должен быть одинаковый типа

local cf = functon()
end

local t = timer.new(24, cf)

а далее его просто проверять

t:check()

Развели....

Много примеров, но все они мало применимы. Какие циклы. Тайме, чаще всего, организуется по месту, а не где-то в main, в одной точке. Далее, чтобы это было удобно, могли бы хоть функцию обратного вызова организовать, чтобы по завершению она была бы вызвана. Иначе зачем он нужен, чтобы напечатать привет...

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

Так они и находятся на сервере брокера и транслируются в терминал. Если Вы не верите записям в терминале и хотите их проверить, то тогда и нужен прямой доступ к записям на сервере. Что, конечно, никогда не будет реализовано. И ни в коем случае недопустимо даже рассматривать такое.

А по таблице сделок не надо бегать, тогда и проблемы не будет. Колбек же, в свою очередь, в ряде случаев требует решения синхронизации данных.
Впрочем, решение на колбеках тоже рабочее. И часто используется. Здесь вопрос предпочтений для конкретного алгоритмического решения.

Система меню, конечно, позволяет изменять настройки, но есть настройки, которые не изменяются при активном алгоритме. Например ТФ баров. Да, Вы опять скажете, что это никому не надо, мне тоже не надо, но кому-то надо. И не мне указывать что и как делать. Поэтому в такой момент скрипт не совершает торговые операции, но при этом ведет контроль позиции и сделок. Поэтому снимать ордера - это не вариант. Судя по всему, у Вас все ордера "рыночные", но вернемся к другим пользователям и окажется, что видов ордеров может быть много. И есть те, кому это надо. И по наблюдениям, рыночные ордера - это не самое распространенное явление.

Что касается обсуждаемой "проблемы", то просмотр прямых таблиц дает гарантию, что если там есть запись, то она не будет пропущена. Если же Вы про гарантии, что запись есть у брокера, но нет в терминале, то это находится в области ошибок работы клиент-серверной архитектуры, рассогласование данных. И это Вы никак не проконтролируете, т.к. у Вас нет методов прямого обращения к данным сервера. Но даже исключение проблемы работы колбеков уже повышает стабильность решений.

Как часто смотреть - постоянно. Если это сделано корректно, то это не вызывает существенных накладных расходов. И смотреть во все необходимые таблицы.
Необходимы сделки - таблица сделок. Необходимы ордера - таблица ордеров. Необходимы данные лимитов по бумагам - таблица depo_limits, куда, собственно, метод getDepoEx и смотрит.
Вы же смотрите в таблицу текущих торгов, и, наверно, постоянно.

Скрипт-то с какой радости "не работал"?

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

А если скрипт временно не работает, то  это не значит, что заявки снимаются (а значит могут быть исполнены). Или Вы предлагаете при каждой остановке скрипта снимать все?

Что же касается учета сделок, то я использую свои колбеки, организованные на выявлении новых записей в таблице сделок. Т.е. я прямо смотрю в таблицы терминала. Да. Можно говорить, что такое решение странное, не красивое и т.д. Но колбек не дает гарантий и на этом разговор заканчивается.

Как я сказал, проблема не в том, что он пришел поздно (хотя даже этого достаточно, чтобы уже задуматься), а в том, что он может быть пропущен (не работал скрипт). И тогда алгоритм скрипта что, пропустил сделку? Это слишком опасно.
И не надо говорить, что такого не будет. Иногда достаточно одного раза. Поэтому в такой важно части необходимо самое надежное решение как базовое. И это не колбек терминала.

Если бы в Квике была гарантированная доставка сообщений, как в RabbitMQ, то да. Но раз нет гарантий, то я не очень понимаю, как можно выбирать это для такого рода решений.

Если Вы используете колбеки, то да. Но если скрипт не работал в момент совершения сделки (пропустили колбек), то это не должно приводить к проблемам в работе скрипта.

Что значит отсутствует. Я Ваш код не видел, а свой вижу. И у меня, ленивого, нет никакого желания сидеть за монитором и контролировать. Зачем тогда автоматизация торговли, если все равно сидишь за терминалом. Много других полезных занятий есть. Поэтому скрипт должен все помнить, считать, проверять, корректировать. А если что-то не так, то пришлет оповещение на почту.

Зачем рассказывать про то как скрипты работают месяцами - это само собой разумеется, а как иначе.

Про баланс, опять, вопрос очень размытый. Баланс брокера - это единая, общая картина. А скрипту же чаще всего необходимо видеть только свое. В этом случае этот баланс что даст?
Вот сделки необходимо считать, да. Надо контролировать лимиты денежных средств, перед подачей транзакции. Иногда, чтобы развернуть позицию необходимо сначала закрыть прошлую, а потом уже открывать новую.
Такие технические моменты необходимы.

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

Да currentbal - это необходимо поле.

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

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


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

есть таблица depo_limits
Вы можете простым перебором получить данные, можете отфильтровать SearchItems и уже их перебрать. И скажу, что это будет надежнее.

Зачем Вы сравниваете с true. Это булевый тип. А таблица - это table.

getFuturesLimit(p_firmid, p_account, 0, "SUR") возвращает таблицу. В ней есть поле cbplimit типа number.

Только сейчас обратил внимание.

Формат вызова функции такой getFuturesLimit(STRING firmid, STRING trdaccid, NUMBER limit_type, STRING currcode)                        

первым идет код фирмы, а не код класса. Это же лимиты всей срочной секции, а не одного класса.
А фирма firmid   = SPBFUT000000

Что-то не очень понятна проблема. Есть методы получения баланса по бумагам, контрактам. Причем для разных типов расчетов. Все что они делают - это передают выдают данные, которые транслирует брокер. Сам терминал ничего не знает про ваши активы. Чем они не угодили?

Правда, в большинстве случаев, скрипт ведет свою позицию, и общая позиция на балансе ему не интересна и даже вредна. Ведь разные скрипты и человек могут вести торговлю одновременно. Один в лонг, другой в шорт - баланс 0, а позиции есть.

Нет. значение же не true, зачем с ним сравнивать. Зада же посмотреть, что в таблице. 4 - цикла, значит там 4 - записи

Лучше выводить не в сообщения, а в лог файл. Но раз через сообщения, то можно так:

Пройдитесь циклом по таблице futures_client_limits и посмотрите, что там. Чаще всего на этом этапе и находится проблема.

Если речь про параметр "Количество сделок за сегодня", то это данные из таблицы Текущих торгов. Имя параметра  NUMTRADES.

Все зависит от задачи.

Если это действительно принятие решения в реальном времени, то тогда и блок анализа должен работать с потоком данным (с заданным периодом квантования времени). Т.е. лучше всего в самом скрипте и организовать.
А если снаружи, то это либо база данных куда будет записываться слепок данных в каждый квант времени (т.е. много данных), либо необходимо успевать анализировать каждый пакет данных и тогда можно сделать на socket или другим способом межпроцессорного взаимодействия.

Для накопления уже проще. Все записывать с заданной периодичностью, с отметкой точки времени, чтобы данные не смешивались. А уже куда записывать - менее важно, хоть и существенно.

Да, но округление не нужно в данной операции.

Можно так, а можно просто math.modf

Только в скобках, т.к. функция возвращает два значения - целую часть и дробную часть

int_x = (math.modf(a/b))

Вот для примера простой скрипт https://github.com/nick-nh/qlua/tree/master/quantScript

Изначально разбивать не надо. Это же арифметическая операция (правда можно кеширование сделать, если память есть).

цена 127 - это целое(127/10)*10 = 120
цена 127 стала 120, т.е. период квантования = 10. Значит все числа из диапазона 120-129 становятся 120. А значит и их объем будет для числа 120.

А как получить объемы по ценам 123 или 134?
Если у Вас задача суммировать обемы сделок по каждой цене, то тогда это более простая задача - просто суммировать объемы с одной и той же ценой.

t ] {}
....

t[123] = (t[123] or 0) + deal.qty

t[134] = (t[134] or 0) + deal.qty


И получите таблицу со всеми объемами, где ключ - это цена, а значение - это объем.

Что касается нефти, то я, обычно, такие числа привожу к целому, умножая на 10 в степени разрядности дробной части. А потом уже провожу манипуляции.

Просто кластиеризуйте ценовой диапазон.

Для примера кластер в 10 рублей.

цена 127 - это целое(127/10)*10 = 120
цена 144 - это 140
цена 142 - это 140

и т.д. Тогда сумма объемов на одинаковых кластерах и даст нужный результат.

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

Загрузка в 12% - это не значит, что одно ядро все занимает. Чтобы однозначно сказать, необходимо открыть монитор ресурсов и посмотреть подробную картину для каждого ядра.

При любой установке соединения с сервером необходимо "ждать" момента когда соединение есть и пропущенные данные получены.
Отследить установку соединения - не проблема. А вот подгрузку данных - уже приходится контролировать некие параметры. Для примера разность времени сервера и времени последнего полученного пакета.
Пока пакеты не "догонят время", стоит подождать.

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

Статус стоп-заявки - это всего лишь индикатор того в каком состоянии заявка на сервере брокера. Исполнилась - значит исполнилось условие.
Далее идет подача команды на установку лимитного ордера по указанным параметрам. Если команда не пройдет шлюз, то можно проверить это через бит 10 и 11 флагов стоп-заявки.
Если же лимитный ордер был установлен, то у стоп-ордера будет заполнено поле linkedorder Номер заявки в торговои? системе, зарегистрированнои? по наступлению условия стоп-цены.
По нему и можно найти лимитный ордер в таблице orders и проверить уже его статус, предпринять какие-то действия.

       

Вопрос целесообразности подписки на колбек.
Если - это необходимо для получения цены сделки внутри бара, то это не лучшая идея, т.к. этот колбек медленный и будут пропуски.А если это для того, чтобы узнать, что пришел новый бар, то не проще ли запомнить прошлый Size и сравнить с новым. Когда придет тогда и делать что-то. А так колбек будет дергаться много раз, ради одного события.

Состояние заявки можно получить в колбеке OnOrder или найти в таблице ордеров запись по номеру ордера order_num (индекс записи можно запомнить).

Из таблицы сделок можно (а значит и из колбека OnTrade), конечно, но это на каждую сделку придется переходить в таблицу ордеров. Если ордер большой, то это уже может быть накладно.
Колбек OnOrder прямо вернет запись таблицы ордеров.

Владимир, заявки могут быть не на закрытие всей позиции.

Не очень понятно зачем именно дата торгов, если есть дата время самой сделки datetime.

На демо серверах такое как раз чаще встречается.


Что же касается вопроса, то не очень понятно, что необходимо сделать. Не подтягивать стоп если это прокол?
Если так, что самое простое - это организовать таймер ожидания функции проверки изменения цены с прошлого опроса. Тогда у Вас проверка будет более большими квантами времени.
Если непрерывно, то, условно, это будет раз в 100 млс. А так - раз в установленное время секунд, скажем раз в 1 сек.

Правда здесь есть вероятность того, что именно во время проверки это аномальное изменение и случится. Для этого можно организовать счетчик. Т.е. если такое случается больше чем 1 раз проверок, то это подтвержденное изменение. Для примера:
Проверяем 1 - нет изменений. Счетчик 0.
Проверяем 2 - есть изменение. Счетчик 1.
Проверяем 3 - уже нет изменения. Счетчик сбрасывается в 0.

В результате изменение пропущено как ложное. Вот если в течении двух отсчетов изменение сохранится, то есть.

Он не поддерживает кодировку Win1251. Квик же в 2022 только ее понимает...
Правда для ZeroBrane можно скрипт на том же lua для перекодировки при открытия файла настроить. Но это не лучший вариант. Часто файлы потом не открываются вообще.

Очень спорное утверждение. Почему не Vim или Emacs?
Notepad++?, если речь про него, хорош если быстренько открыть водном файле, посмотреть, закрыть.

Установить в настройках кодировку по умолчанию win1251.
Можно только для рабочей зоны, можно доля всех файлов lua. По желанию.

Для примера:

По всей видимости, это был сарказм. Окружение терминала в рамках qlua не предоставляет методов по доступу к окну доступных скриптов lua.

Вариантов два:
-- Разобраться с утечкой памяти. Это будет единственно правильным решением.\
-- Написать некий proxy-метод в библиотеке, который будет приводить к перезапуску основной логики. И дергать его по таймеру уже из скрипта lua или прямо организовать цикличность в запуска в самой библиотеке.

Правда есть еще вариант: написать скрипт, использующий w32.dll. Найти окно доступных скриптов, виртуально нажать кнопки остановки и запуска. Для примера, как это сделано в автологинах.

Если я правильно помню luasql от keplerproject под win32. Возьмите сборку под x64, хотя бы от swerg https://github.com/swerg/qlua-luasql
Либо сами внесите изменения.

И соберите через make или прямо в VC.