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

Подниму тему.

Читаем справку:

Универсальный формат позволяет отправлять любые транзакции, если известно их  описание

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

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

Получаем:

Ошибка выставления лимитной заявки: Не найдено поле "Код клиента" для транзакции "Ввод заявки" по классу "Акции 1-го уровня (эмулятор)"

Убираем поле "Код клиента" - работает. Но как же так, код-то нужен. Код видно только в поле "Примечание" вместе с введённым комментарием.


Внимание вопрос: это так демо-сервер работает или лыжи не едут...

Этот квест с универсальным форматом просто великолепен. Если бы сделали перенос заявки в фиксированном формате, то, видимо, никто бы не задавал больше вопросов. Но нет...

Согласен, но иногда просто слов нет. Да и в двух словах не опишешь проблему.

Индексы от 0. Т.е. первая строка - это индекс 0.

Да, у меня выделенный IP адрес. Но я очень сомневаюсь в его влияние. В 90-е, ещё можно было ожидать, что как-то будут его учитывать, но уже с 00-х он стал бесполезен. С учётом того, что большинство участников живёт за разными шлюзами, прокси серверами, используя "плюшевые" адреса, совершенно не подозревая какой у них адрес. Подозреваю, что здесь связь по типу P2P с использованием некого уникального ключа-токена установленного соединения.

Ну и если говорить о смешивании пакетов в терминах баз данных, я бы понял если бы было полное соединение, а здесь левое. Только в одном терминале подмешана информация от другого, и только таблица ордеров. Баланс счёта, да и сами счета субсчета не смешаны.

Да, оба терминала версии 11.4.0.54

Брокер Сбербанк. Действие 24.01.2025

Есть два брокерских счёта у него. Два терминала Квик. После очередного обрыва связи, которые на этой неделе почти каждый день, ордера из одного брокерского счёта стали видны в таблице Квика другого брокерского счёта. Буквально - есть записи с несуществующим кодом клиента для этого счёта, терминала. Что ещё забавно, если снять ордер в этом терминале (хотя этот ордер не принадлежит этому брокерскому счёту), то он также снимается и в другом. Вот такая загогулина. Если бы не было печально, то, наверно, можно было бы посмеяться. Возникает вопрос - как серверная часть терминала допускает такое? А если бы стали видны ордера совсем другого клиента?

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

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

sleep обычно небольшой от 10 до 60 млс. Зачем 200 сразу.
Сделки надо учитывать, да. Но их можно очищать уже через день. Даже на след. день, исключая те, что в вечернюю сессию на срочном рынке. Их и с колбеками необходимо учитывать, т.к. колбек может и приходит несколько раз на одно событие. А значит чтобы исключить повторный учёт, необходимо их запомнить. Особой проблемы в этом нет.


Да, будет. По одному ордеру может быть неограниченное число сделок, если представить такой ордер.

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

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

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

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

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

Это уже новая информация. Какая минимальная версия терминала, поддерживающая данную функциональность?

И сразу возникает вопрос: как будут работать методы, где есть входной параметр limit_kind?

Сообщение в терминале увидел. Вот оно, чтобы было понятно остальным:

Здравствуйте.С 16 января сервер QUIK Junior переведен на современную схему ведения позиций - по календарным датам. Если ранее каждой позиции соответствовал код расчетов (T0, T1, T2), то теперь - конкретная дата.
Например, если сегодня 16.01.2025, значит код расчета T0 соответствует дате расчета 16.01.2025, код T1 - 17.01.2025 и так далее. Ожидается, что в будущем на эту схему перейдет большинство брокерских компаний. Кроме того, теперь расчеты по всем инструментам на сервере происходят по схеме T+1, что соответствует режиму реальных торгов на Московской Бирже.
В связи с этим в таблицах с позициями по инструментам и деньгам следует заменить параметр "Срок расчетов" на "Дата расчетов". В таблице "Состояние счета" вместо кодов расчета теперь подставляется конкретная дата.


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

Сегодня на тестовом контуре в таблице depo_limit получил такое:

limit_kind = 20250116

Это что? Ясно что дата. Но с какой такой... Я не слышал о новом режиме торгов в виде даты. Есть Т0, Т+1, Т+2, TOD, TOM и новое Т365, отображаемое в терминале Тх.

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

Так что я лучше проверю руками в самом источнике информации. Тем более, что этот контур всё равно необходимо реализовывать, например, при перезапуске скрипта. Колбеки прошли давно, а понять ситуацию необходимо сейчас.

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

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

Пишите сервере на lua, открываете наружу порт и пожалуйста. Правда смелость этого решения высока.

В папке socket должны быть еще файлы lua, реализующие протоколы.

Ищите библиотеку socket. Она поддерживает http. Безопасное соединение не поддерживает, для этого необходимы дополнительные библиотеки, в частности luasec.

Справедливости ради - это не среда Linux. Вот если бы терминал был нативный для Linux - это было бы прекрасно.

Проще сделать автосинхронизацию каталогов. Изменяя базовый, остальные зеркалируются.

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

А причём здесь Квик? Где изменение данных в переменой localtime. Оно как осталось от инициализации так и не изменяется.

Как пользователь MacOS уже более 15 лет был бы раз видеть это. Но так уж сложилось в мире финансов - основные профессиональные инструменты на Windows. И это не только здесь, но и по всему миру так.
Это положение изменяется  постепенно, но не в ту сторону как хотелось бы. Теперь все делается на серверах Linux как backend, а интерфейс рисуют через Web приложение, что ужасно. Это пусть для масс. Проф. участники продолжают использовать свои решения и Mac там представлен минимально.

Так что не ждите, особенно сейчас, когда доля устройств на пространстве Quik Mac мизерна. Linux даже больше. Вот для него дистрибутив не мешало бы делать, во избежание казуса, если все перестанет работать.

Тестовый контур Quik Junior 11.3.2.2

Ответ транзакции:
[INFO  2024-09-18 13:13:09] : OnTransReply all trans count: 8 | sec_code SiZ4 result_msg: Ответ из торговой системы не получен, статус исполнения транзакции неизвестен. За уточнением просьба обратиться к Вашему брокеру. status: 4 trans_id: 50553350 order_num: 0 price: 80013 qty: nil account SPBFUT000i4 client_code SPBFUT000i4 firmid nil brokerref SPBFUT000i4//NTR01


Не то чтобы нужен ответ, но просто хотелось бы понять причину. Это что-то новое: запрос сделан, ответ - кто же знает что там случилось.

Плюс, возможно, еще нужен НКД - это параметр ACCRUEDINT

Для облигаций сложнее, т.к. они представлены в виде процента от номинала. Поэтому необходимы параметры:

текущая цена - LAST
номинал - SEC_FACE_VALUE

сответственно стоимость - это цена*номинал/100


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

Стоимость лота - это стоимость одного инструмента на количество бумаг в лоте. Количество в лоте - это параметр LOTSIZE.
Цена одного инструмента - это уже сложнее для части инструментов, но для акций - это просто цена.

В очередной раз инструкция, справка Квика - это вещь в себе.

В чем проблема через известный объем узнать число лотов и подать транзакцию?

Возможно вопрос был про класс "неполные лоты" для которого имело бы смысл знать остаток.

Только не забудьте, что протокол https, т.е. требуется поддержка TSL.

io.popen в окружении терминала все равно поднимает окно.

Не использовать curl из командной строки, а написать библиотеку, клиента, реализующую обмен и передачу информации прямо через http запрос.

Потому что подключение неправильное.

local sqlite3 = require("lsqlite3")


Смотрите примеры http://lua.sqlite.org/index.cgi/dir?ci=tip&name=examples

Собирать надо проект http://lua.sqlite.org/index.cgi/home

Вот собранное https://github.com/nick-nh/qlua/tree/master/luasqlite3 на lua 5.4. В терминале работает.

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

Это новая реализация, пока без денег. Потом, как обычно, будет за деньги.

Данный API ничего не изменит, т.к. это средство для разработки. Чтобы его использовать нужен клиент, читай терминал, в том или ином виде. А самый знакомый и уже давно используемый - это Квик.
Вот если брокеры массово начнут писать свои терминалы, тогда возможно. Но это крайне маловерятно. По крайней мере для меня, терминал должен быть не как Web приложение (и даже не на C#), которые сейчас лепят везде, даже там где это бессмысленно.

1С как платформа для роботов - это из области использования сковородки для глажки одежды. Вот как система учета портфеля, сделок, может даже подачи транзакций через файлы и папку обмена Квик - в самый раз. Хотя и это создает ряд сложностей, т.к. это либо установка на конкретном рабочем месте, либо web клиент, что уже требует совсем других затрат на поддержание. Это не говоря уже о скорости работы 1С. Это даже хуже Питона.

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

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

По моим наблюдениям само число графиков не особо влияет на скорость (но потребление памяти расчет). Индикаторы, если встроенные тоже не особо влияют. А вот если масштаб графика мелкий, т.е. показывается большое число бар, уже сильно влияет. Иногда покажешь большое число бар, порядка 5-10 тыс. и интерфейс всего терминала ощутимо замедляется. Так что проверьте на своих графиках масштаб.

Возможно и это. Хотя после восстановления соединения, по идее, данные должны были дойти. Тем более что новые ордера устанавливались корректно, по ним данные приходили. А вот эти старые зависли.
Для обычной пользовательской работы это просто неприятная неожиданность, а вот алгоритм уже не в состоянии адекватно понять, как такое возможно.

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

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

Так что еще стоит проверить нагрузку терминала на систему, диск.

Вы бы хотя бы какую-то информацию предоставили - версия терминала, темная или светлая тема, объем оперативной памяти рабочего места, установлен ли антивирус и т.д.

Да, это 11.07.2024. Скрипты были включены. Снятие этих заявок приводило к ошибке о невозможности снять.

Был разрыв связи. Во время простоя заявки исполнились. Восстановление связи. Заявки остались активные. Пришли только колбеки OnTrade. Колбеки на ордера не пришли. Статусы ордеров остались активные.

Версия 11.3.1.2, демо-сервер ARQA

Вот такая замечательная картина. Ордера на покупку.

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


В общем случае алгоритм с единичным действием вставки элемента имеет константную сложность O(1), а тот, где есть сдвиги - О(n). Так что даже вопроса нет что быстрее.А скорость расчета индекса - это не то, что сильно повлияет на производительность в случае О(1).

Что это значит "динамически меняющего индекс, длину и веса"? Если речь про очередь, стек, то одна задача. Если речь про хранение в массиве определенного числа элементов, скажем 100 и не более, то это другая.