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

Вопрос к Тех. поддержке:

поправлю, в ±2^53, если быть более точным

Пока что я выяснил следующее...

Появились эти новые статусы «14», «15» и «16» начиная с версии Quik 7.6.0. Описаны в «Руководстве пользователя Quik» (info.chm), «Раздел 3. Просмотр информации», подразделы «Таблица транзакций» и «Таблица транзакций \ Настройка таблицы».

Перечитал описание несколько раз, но ясности это не прибавило. Например, у меня в Quik'е если создать эту таблицу транзакций, то там из действий есть только пункт ««Оповещение по статусу транзакции»», а должны быть ещё два пункта «Новая заявка» и «Контроль дополнительных ограничений». Вот как раз через этот пункт «Контроль дополнительных ограничений» и должен открываться некий диалог, где можно нажимая кнопки «Да» и «Нет» разрешить или отменить транзакцию. И это должно привести к получению OnTransReply со статусами «15» и «16» соответственно. Возможно я пытался в нерабочее время, попробую снова когда будет торговая сессия.

Самое интересное, что в описании «Таблица транзакций \ Настройка таблицы» фильтра «Статус» сказано, что «Успешные» это транзакции со статусами «3», «15» и  «16», а все остальные статусы соответственно «Отвергнутые». То-есть, логика видимо такая, что отвергнутая пользователем транзакция тоже успешная, так как была кем-то обработана... но для целей скрипта такая трактовка не годится, так как успешная транзакция это та, которая оставляет после себя заявку, с которой дальше можно работать, а если транзакция отвергнута пользователем со статусом «16», то в рамках Lua скрипта это всё равно ошибочная транзакция.

Мне стало любопытно, и я просканировал все диалоги из lang_res.dll (ресурсная библиотека Quik), но кроме диалога настройки таблицы транзакций не нашёл больше никакого, где спрашивали бы о «Контроле дополнительных ограничений». Но эти «дополнительные ограничения» упоминаются во множестве строковых ресурсов, видимо Quik должен выбрасывать общее окно, как при подтверждении ввода заявки, и там можно отвечая «Да» и «Нет» сгенерировать эти самые статусы «15» и «16»... вообщем, пока непонятно, ни где эти дополнительные ограничения ставить, ни как отвечать на транзакции попавшие под эти ограничения.

То-есть, на текущий момент остаюсь при том же мнении, что успешность необходимо проверять двойным условием на статусы «3» и «15»...

Как правильно проверять успешность обработки транзакции?

Сейчас делаю так:
1. ответы со статусом «0» и «1» об успешной отправке и получении транзакции сервером — игнорирую
2. ответ со статусом «3» о выполнении транзакции — считаю успешной обработкой транзакции
3. ответы со статусами «>=2, но кроме 3» о разных ошибках и прочем — считаю ошибкой при обработке транзакции

Меня смущает код «15», по документации он описан как «транзакция принята после нарушения дополнительных ограничений».
В каких случаях и для каких типов транзакций он приходит? Для NEW_ORDER, для KILL_ORDER или для обоих?

Соответственно, нужно ли проверять успешность обработки транзакции двойным условием на оба кода «3» и «15»?

Зайдите на страницу:
https://arqatech.com/ru/support/files/

Там почти в самом низу скачайте:
«Документация по языку LUA в QUIK и примеры zip, 5.6 МБ»
https://arqatech.com/upload/iblock/194/quik_lua.zip

В архиве посмотрите файл «Использование Lua в Рабочем месте QUIK.pdf», там всё подробно расписано со схемами и примерами кода.
Особенно главу «4. Отправка транзакций из Lua скрипта», там пример работы с OnTransReply.

По идее именно для этого и нужен trans_id, по которому определяется ответ на посланную транзакцию. При посылке NEW_ORDER задаётся один trans_id, а при посылке KILL_ORDER другой trans_id. Соответственно ответы приходящие в OnTransReply различаются по этим разным trans_id.

Тем лучше для Quik. Сервер Quik может сохранять trans_id для перевыставленных заявок, а не обнулять его.

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

Скрипт Lua получает вызовы OnTransReply (и других событий) на транзакции посланные из других скриптов Lua, и в целом идущие от:
• Lua
• Trans2quik.dll
• QPILE
• динамическая загрузка транзакции из файла

Если идентификатор транзакции в одном скрипте Lua совпадёт в таким же в другом скрипте Lua, то возникнет путаница, когда чужие ответы будут приняты за свои. Такого быть не должно.
Функция AllocTransID() должна гарантировать уникальность получаемого идентификатора между всеми типами клиентов Quik.

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

Нет, не пробовал... но суть не в конкретном обфускаторе как таковом, а в самом способе защиты алгоритма. Алгоритм остаётся открытым, его можно вытащить. Причём, по сути, пошаговым рефакторингом обфускаренного кода. Отрезая лишнее и ненужное. Многие сочтут такую работу за удовольствие, и с радостью поработают над вашими 200 КБ превращая их обратно в исходные 20 КБ.. )))

Абсолютно неправильная точка зрения. Безопасность как раз и начинается с открытого обсуждения способов защиты. Специалисты устраивают конференции ежегодные, доклады готовят, а не сидят по домам втихую пряча все свои секреты.

Как раз думаю над подобным способом, но только через общую (разделяемую, shared) память процессов. Это наиболее быстрый способ обмена. Делал его 20 лет назад ещё на VS6.0 через директивы компилятора. Но тут речь о том, как бы не городить огород. Хочется оставить Lua в обороте с одной стороны имея возможность прямой загрузки скрипта в Quik, а с другой стороны возможность быстро пересобрать проект в защитной конфигурации. Пока что вижу только реально практически удобный способ с делением кода на две части, как наименее затратный для реализации подобной схемы защиты. Фактически «иерархия конечных автоматов» биржевого протокола и обмена с Quik остаётся в Lua скрипте, а сама торговая стратегия уходит в отдельную DLL с мостом через shared-память.

Да, может. )))
Единственно что не все файлы, так как такую дисковую активность несложно отследить, и палиться так разработчики Quik'а не станут, я полагаю. Но вот, то что уже загружено в Quik, то-есть сами .lua и .luac файлы без проблем могут передаваться на строну сервера Quik, и отследить такую активность не взломав протокол Quik'а с сервером уже невозможно.

Вернулись к началу темы... по кругу ходим. Уже же выяснили что luac не выход. Даже если его просто в редакторе открыть, видно, что все имена сохранены.

Я пробовал свои luac файлы декомпилировать через unluac обратно в lua, результат поразительный. Получил точную копию исходного lua файла. Отличие только в отсутствие комментариев. Даже структура отступов совпала.

То-есть для «вскрытия алгоритма» это более чем достаточно, фактический исходный код как он есть. Уж лучше тогда оставить Lua код с комментариями, в которых хотя бы можно авторские права указать. )))

Порядок одно, а целостность протокола совсем другое. В данном случае, речь идёт о потери связи между начальными и конечными сообщениями в рамках транзакции.
Ситуация возникает из-за обнуления trans_id для перевыставленных заявок. А также из-за отсутствия в сделках информации об исходной заявке.

Детский сад продолжается...

Что имелось ввиду мы уже не узнаем, ибо это большая тайна...

Что же касается связки luac + bin2c, то она не сработает в качестве защиты. Там нет компиляции кода. Там просто упаковка luac кода в секцию данных и с последующим вызовом по указателю. А это значит, что обычным Hex редактором (и/или даже 7-Zip архиватором) этот luac можно вытащить обратно.

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

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

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

Обфускатор, в качестве защиты, мало что даёт на самом деле.

Детский сад какой-то...

у вас там какая-то DLL-обёртка написана, которая перенаправляет OnOrder, OnTrade и пр. в одноименные вызовы скомпилированного в бинарник Lua-скрипта?

Очень плохая ситуация... если OnOrder с новым order_num потерялся... то все последующие OnTrade невозможно ни к чему привязать, так как старого order_num в них нет.
Фактически это «сделки из ниоткуда»... у них trans_id нулевой, linkedorder нет и order_num новый.

не... я понял фразу «встраивание скрипта на луа в dll» буквально, что вы вовнутрь DLL перенесли Lua код как он есть... на подобии двоичной компиляции... а потом это дело прикрутили к Quik...

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

как бы это сделать по-человечески?...

Столкнулся с этим же при попытке использования ZeroBrane Studio, которая, насколько я понял, работает исключительно с UTF-8. А Quik наоборот, работает исключительно с Win CP1251, иначе выдаёт ошибку загрузки скрипта.

Как бы их скрестить по-человечески?... кто-то пробовал?

А можно поподробнее?... и как всё это прикручивается к Quik в конечном счёте.

работает возможно из-за того, что вы для срочного рынка считаете... а для фондового может уже так не сработает...

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

***
По теме... я ещё не разбирался с функцией CalcBuySell, поэтому не знаю что там за параметр client_code ей требуется... у меня поле с таким именем в OnTransReply, OnOrder и OnTrade точно равно полю account, а в вызове sendTransaction оно задаёт комментарий, который возвращается потом полем brokerref... то-есть полная путаница получается...

Подозреваю, что в вызове CalcBuySell параметр с таким же именем client_code должен задавать значение, которое возвращается в поле uid в OnTransReply, OnOrder и OnTrade, это уже пусть тех. поддержка точно скажет...

Тогда, если это так, то может вытащить это значение оттуда из uid? это так на вскидку, не зная структуры вашего кода...

...до последнего казалось, что linkedorder будет содержать номер самой первой заявки...

Наверно, очевидно, что это совсем не очевидная вещь, и её стоит добавить в документацию... можете зарегистрировать пожелание?

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

Тогда уже, если развить тему, то число, указанное в документации Lua, не совсем точное. Не знаю почему так.

На самом деле границы диапазона взаимно-однозначного перевода целых чисел между типами double и __int64 составляют:Это чуть более чем в 90 раз больше, чем по документации Lua:То-есть, в строковом представлении число длиной в 15 десятичных цифр точно. (16 цифр неполностью)

Судя по описанию торговой платформы ASTS (Фондовый и Валютный рынки МосБиржи), которое я нашёл,
идентификационный номер заявки в Торговой Системе — поле ORDERNO, имеет тип INTEGER и размер 12.
То-есть задаётся строкой длиной в 12 символов, или соответственно числом длиной 12 цифр.
Что на приблизительно 2-е цифры больше чем максимально-возможное значение 32-хбитного типа int,
но гораздо меньше, чем максимально-возможное точное целочисленное значение типа double:
Так что, получается, что типа lua_Number (от же double) достаточно для точной передачи номера заявки в торговой системе Фондового и Валютного рынков МосБиржи.

SG прав...

ошибка в строчке:добавлю только, что судя по определению:произошло преобразование значения типа double превышающего максимально возможное значение типа int, в результате чего было получено значение INT_MIN из <climits> (limits.h)

А когда несколько дней подряд заявка переносится и её номер меняется через каждый вечерний клиринг несколько раз, то значение linkedorder содержит номер самой первой заявки в самый первый день? или linkedorder  содержит номер заявки за предыдущую торговую сессию?

То-есть, чередование значений такое:
1-ый день: order_num = 0001, linkedorder = 0001
2-ой день: order_num = 0002, linkedorder = 0001
3-ий день: order_num = 0003, linkedorder = 0001
4-ый день: order_num = 0004, linkedorder = 0001
5-ый день: order_num = 0005, linkedorder = 0001

Или такое:
1-ый день: order_num = 0001, linkedorder = 0001
2-ой день: order_num = 0002, linkedorder = 0001
3-ий день: order_num = 0003, linkedorder = 0002
4-ый день: order_num = 0004, linkedorder = 0003
5-ый день: order_num = 0005, linkedorder = 0004

Всем ответившим спасибо за предыдущие ответы...

Ещё вопрос по очерёдности OnOrder и OnTrade при замене заявки со сроком действия при переносе через вечерний клиринг на срочке.

По логам, OnOrder для новой заменённой заявки приходит с trans_id == 0, новыми order_num и datetime, и linkedorder равным order_num старой заявки.
Насколько я понимаю, OnTrade также придёт с trans_id == 0, новым order_num, но без linkedorder, так как такого параметра в сделках нет.
Единственный способ связать между собой новые сделки по новой заменённой заявке, это сравнить новый order_num в OnTrade с новым order_num полученным в OnOrder.
Но для этого, OnOrder для новой заменённой заявки должен обязательно прийти первым. По логам вижу, что он пришёл в середине вечернего клиринга вчера.

Возможна ли ситуация, что до начала торговой сессии не придёт OnOrder с новым order_num, а первым придёт в начале новой торговой сессии OnTrade с этим новым order_num?
Или гарантируется, что при заменах, OnOrder с новым order_num будет приходить всегда первым и до начала новой торговой сессии?

Пожалуйста, уберите с формы ответа обработчик Ctrl+Enter как горячую клавишу кнопки «Отправить»... эта комбинация в Skype при редактировании делает перенос на новую строчку. По привычке постоянно нажимаю её, и сообщение сразу же отправляется на форум Quik недописанным. И нет возможности его исправить...

Сюда же задам ещё два вопроса по поведению OnTransReply, OnOrder и OnTrade, чтобы не плодить темы.

1. Возможна ли ситуация потери одного из вызовов, например при сетевых ошибках, сбоях сервера и т.п... то-есть OnTransReply вообще не приходит, а сразу приходят OnOrder и OnTrade?
2. Возможна ли ситуация изменения порядка прихода вызовов. Например, первым придут несколько OnTrade, за ними OnOrder и в конце OnTransReply, и все разумеется в рамках одного trans_id?

Значит ответ: «Да»...

По документации, поле order_num может быть nil в OnTransReply(trans), а в OnOrder(order) нет.

Возможна ли ситуация, что в ответ на NEW_ORDER придёт успешный OnTransReply(trans) с trans.status == 3 в котором trans.order_num == nil?
То-есть, заявка будет успешно зарегистрирована, но её номер останется неизвестным. И придёт только в поле order.order_num ~= 0 при последующем вызове OnOrder(order) имеющим такой же идентификатор транзакции order.trans_id == trans.trans_id.

...и судя по логам, бит номер 17 (0x20000) в флагах транзакций, если нумерация с 0 как в документации по флагам заявок и сделок. Если нумерация с 1, то тогда 18-ый получается.

Можно уже закладываться на это, не дожидаясь включения в официальную документацию?

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

OnTransReply(TABLE trans_reply)

В trans_reply есть параметр определяющий направление операции (Купля/Продажа)?

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


Я вам сочувствую.


А от появления разных эксплойтов, в том числе неопубликованных и тех для которых ещё не выпущены обновления системы, вы как защищаетесь? магией?

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

А как между собой соотносятся версии сервера и клиента, который брокер рассылает с этого сервера, они связаны? Номера должны совпадать?

01.03.2018 брокер обновил версию клиента до 7.16.2.5, предыдущая версия клиента скачиваемая с его сервера была 7.14.1.7 в течение как минимум полугода.
По вашим словам у брокера до сих пор версия младше 5.18, а клиента он рассылает последнего 7.16.2.5.
Такая ситуация нормальная? Разве не должно иди обновление в паре (клиент/сервер) одновременно, чтобы версии с обоих сторон соответствовали.

Пустой brokerref в OnTransReply.

Версия терминала Quik 7.16.2.5, брокер ВТБ, UID 29135 оставил в логах, номер торгового счёта ACCOUNT затёр на всякий случай.
Далее, полная информация по заявке 29666422467 и сделке 1982204382 по ней. Обе прошли в 22:26:51 02.03.2018.

Функция sendTransaction:

Скрытый текст
-- Table: {1} {   ["action"]="NEW_ORDER",   ["trans_id"]="1",   ["operation"]="S",   ["client_code"]="CC trans_id=1 Sell",   ["seccode"]="SiH8",   ["quantity"]="1",   ["comment"]="LUA trans_id=1 Sell",   ["classcode"]="SPBFUT",   ["price"]="56934",   ["account"]="-----------", },

Функция OnTransReply (пустой brokerref выделил):

Скрытый текст

-- Table: {3} {   ["sec_code"]="SiH8",   ["price"]=56934,   ["client_code"]="-----------",   ["balance"]=0,   ["time"]=222651,   ["status"]=3,   ["local_time"]=31821.965,   ["first_ordernum"]=0,   ["date_time"]={6},   ["gate_reply_time"]={7},   ["class_code"]="SPBFUT",   ["trans_id"]=1,   ["error_source"]=0,   ["exchange_code"]="",   ["uid"]=29135,   ["error_code"]=0,   ["flags"]=2490369,   ["result_msg"]="Заявка 29666422467 успешно зарегистрирована.",   ["brokerref"]="",   ["firm_id"]="SPBFUT",   ["quantity"]=1,   ["order_num"]=29666422467,   ["server_trans_id"]=1280,   ["account"]="-----------", }, -- Table: {6} {   ["week_day"]=5,   ["hour"]=22,   ["ms"]=479,   ["mcs"]=479914,   ["day"]=2,   ["month"]=3,   ["sec"]=51,   ["year"]=2018,   ["min"]=26, }, -- Table: {7} {   ["week_day"]=1,   ["hour"]=0,   ["ms"]=0,   ["mcs"]=0,   ["day"]=1,   ["month"]=1,   ["sec"]=0,   ["year"]=1601,   ["min"]=0, },

Таблица заявок:

Скрытый текст

Номер            29666422467,000000     Дата            02.03.2018     Выставлена (время)    22:26:51     Бумага            SiH8 [FORTS: Фьючерсы]     Операция        Продажа     Цена            56934,000000     Кол-во            1,000000     Остаток            0,000000     Объем            56934,000000     Состояние        Исполнена     Дата снятия                 Снята (время)             Срок                     Время активации             Комментарий        CC trans_id=1 Sell     ID транзакции        1,000000

Функция OnOrder:

Скрытый текст

-- Table: {2} {   ["withdraw_datetime"]={7},   ["revision_number"]=0,   ["price"]=56934,   ["investment_decision_maker_short_code"]=0,   ["value_entry_type"]=0,   ["expiry_time"]=-1,   ["balance"]=0,   ["ext_order_flags"]=0,   ["repo_value_balance"]=0,   ["value"]=56934,   ["qty"]=1,   ["price_currency"]="",   ["datetime"]={8},   ["passive_only_order"]=0,   ["local_time"]=31822.15,   ["class_code"]="SPBFUT",   ["investment_decision_maker_qualifier"]=0,   ["activation_time"]=0,   ["userid"]="",   ["client_short_code"]=0,   ["expiry"]=-1,   ["flags"]=28,   ["client_qualifier"]=0,   ["on_behalf_of_uid"]=0,   ["settle_currency"]="",   ["linkedorder"]=0,   ["extref"]="",   ["visible"]=0,   ["ordernum"]=29666422467,   ["sec_code"]="SiH8",   ["ext_order_status"]=0,   ["filled_value"]=0,   ["price2"]=0,   ["canceled_uid"]=0,   ["side_qualifier"]=0,   ["client_code"]="-----------",   ["accepted_uid"]=0,   ["firmid"]="SPBFUT",   ["executing_trader_qualifier"]=0,   ["yield"]=0,   ["reject_reason"]="",   ["capacity"]=0,   ["acnt_type"]=0,   ["repo2value"]=0,   ["start_discount"]=0,   ["min_qty"]=0,   ["executing_trader_short_code"]=0,   ["exec_type"]=0,   ["order_num"]=29666422467,   ["repovalue"]=0,   ["repoterm"]=0,   ["accruedint"]=0,   ["account"]="-----------",   ["seccode"]="SiH8",   ["uid"]=29135,   ["brokerref"]="CC trans_id=1 Sell",   ["exchange_code"]="",   ["settlecode"]="",   ["awg_price"]=0,   ["trans_id"]=1,   ["bank_acc_id"]="", }, -- Table: {6} {   ["withdraw_datetime"]={15},   ["revision_number"]=0,   ["price"]=56934,   ["investment_decision_maker_short_code"]=0,   ["value_entry_type"]=0,   ["expiry_time"]=-1,   ["balance"]=0,   ["ext_order_flags"]=0,   ["repo_value_balance"]=0,   ["value"]=56934,   ["qty"]=1,   ["price_currency"]="",   ["datetime"]={16},   ["passive_only_order"]=0,   ["local_time"]=31822.137,   ["class_code"]="SPBFUT",   ["investment_decision_maker_qualifier"]=0,   ["activation_time"]=0,   ["userid"]="",   ["client_short_code"]=0,   ["expiry"]=-1,   ["flags"]=28,   ["client_qualifier"]=0,   ["on_behalf_of_uid"]=0,   ["settle_currency"]="",   ["linkedorder"]=0,   ["extref"]="",   ["visible"]=0,   ["ordernum"]=29666422467,   ["sec_code"]="SiH8",   ["ext_order_status"]=0,   ["filled_value"]=0,   ["price2"]=0,   ["canceled_uid"]=0,   ["side_qualifier"]=0,   ["client_code"]="-----------",   ["accepted_uid"]=0,   ["firmid"]="SPBFUT",   ["executing_trader_qualifier"]=0,   ["yield"]=0,   ["reject_reason"]="",   ["capacity"]=0,   ["acnt_type"]=0,   ["repo2value"]=0,   ["start_discount"]=0,   ["min_qty"]=0,   ["executing_trader_short_code"]=0,   ["exec_type"]=0,   ["order_num"]=29666422467,   ["repovalue"]=0,   ["repoterm"]=0,   ["accruedint"]=0,   ["account"]="-----------",   ["seccode"]="SiH8",   ["uid"]=0,   ["brokerref"]="CC trans_id=1 Sell",   ["exchange_code"]="",   ["settlecode"]="",   ["awg_price"]=0,   ["trans_id"]=0,   ["bank_acc_id"]="", }, -- Table: {7} {   ["week_day"]=1,   ["hour"]=0,   ["ms"]=0,   ["mcs"]=0,   ["day"]=1,   ["month"]=1,   ["sec"]=0,   ["year"]=1601,   ["min"]=0, }, -- Table: {8} {   ["week_day"]=5,   ["hour"]=22,   ["ms"]=484,   ["mcs"]=484000,   ["day"]=2,   ["month"]=3,   ["sec"]=51,   ["year"]=2018,   ["min"]=26, }, -- Table: {15} {   ["week_day"]=1,   ["hour"]=0,   ["ms"]=0,   ["mcs"]=0,   ["day"]=1,   ["month"]=1,   ["sec"]=0,   ["year"]=1601,   ["min"]=0, }, -- Table: {16} {   ["week_day"]=5,   ["hour"]=22,   ["ms"]=484,   ["mcs"]=484000,   ["day"]=2,   ["month"]=3,   ["sec"]=51,   ["year"]=2018,   ["min"]=26, },

Таблица сделок:

Скрытый текст
Номер        1982204382,000000 Дата сделки    02.03.2018 Время        22:26:51 Заявка        29666422467,000000 Бумага        SiH8 [FORTS: Фьючерсы] Операция    Продажа Цена        56935,000000 Кол-во        1,000000 Объем        56935,000000 Комментарий    CC trans_id=1 Sell ID транзакции    1,000000

Функция OnTrade:

Скрытый текст

-- Table: {2} {   ["settle_date"]=20180305,   ["otc_post_trade_indicator"]=0,   ["period"]=1,   ["exchange_comission"]=0.8,   ["settlecode"]="T1",   ["qty"]=1,   ["local_time"]=31822.118,   ["capacity"]=0,   ["canceled_uid"]=0,   ["seccode"]="SiH8",   ["clearing_firmid"]="",   ["canceled_datetime"]={8},   ["account"]="-----------",   ["linked_trade"]=0,   ["side_qualifier"]=0,   ["client_short_code"]=0,   ["firmid"]="SPBFUT",   ["executing_trader_qualifier"]=0,   ["trade_currency"]="SUR",   ["accrued2"]=0,   ["trans_id"]=1,   ["repovalue"]=0,   ["order_price"]=0,   ["accruedint"]=0,   ["uid"]=29135,   ["start_discount"]=0,   ["station_id"]="",   ["order_qty"]=0,   ["price"]=56935,   ["trade_num"]=1982204382,   ["lower_discount"]=0,   ["cpfirmid"]="",   ["order_exchange_code"]="",   ["clearing_bank_accid"]="",   ["class_code"]="SPBFUT",   ["userid"]="",   ["tradenum"]=1982204382,   ["datetime"]={9},   ["liquidity_indicator"]=0,   ["kind"]=1,   ["ordernum"]=29666422467,   ["exec_market"]="",   ["repoterm"]=0,   ["extref"]="",   ["investment_decision_maker_short_code"]=0,   ["mleg_base_sid"]=-1,   ["value"]=56935,   ["waiver_flag"]=0,   ["client_code"]="-----------",   ["investment_decision_maker_qualifier"]=0,   ["lseccode"]="",   ["client_qualifier"]=0,   ["yield"]=0,   ["on_behalf_of_uid"]=0,   ["ext_trade_flags"]=0,   ["upper_discount"]=0,   ["repo2value"]=0,   ["system_ref"]="",   ["tech_center_comission"]=0,   ["executing_trader_short_code"]=0,   ["reporate"]=0,   ["order_num"]=29666422467,   ["exchange_code"]="",   ["price2"]=0,   ["settle_currency"]="",   ["order_revision_number"]=0,   ["flags"]=68,   ["cross_rate"]=0,   ["brokerref"]="CC trans_id=1 Sell",   ["sec_code"]="SiH8",   ["block_securities"]=0,   ["clearing_comission"]=0,   ["broker_comission"]=0,   ["bank_acc_id"]="", }, -- Table: {3} {   ["settle_date"]=20180305,   ["otc_post_trade_indicator"]=0,   ["period"]=1,   ["exchange_comission"]=0.8,   ["settlecode"]="T1",   ["qty"]=1,   ["local_time"]=31822.124,   ["capacity"]=0,   ["canceled_uid"]=0,   ["seccode"]="SiH8",   ["clearing_firmid"]="",   ["canceled_datetime"]={10},   ["account"]="-----------",   ["linked_trade"]=0,   ["side_qualifier"]=0,   ["client_short_code"]=0,   ["firmid"]="SPBFUT",   ["executing_trader_qualifier"]=0,   ["trade_currency"]="SUR",   ["accrued2"]=0,   ["trans_id"]=1,   ["repovalue"]=0,   ["order_price"]=0,   ["accruedint"]=0,   ["uid"]=29135,   ["start_discount"]=0,   ["station_id"]="",   ["order_qty"]=0,   ["price"]=56935,   ["trade_num"]=1982204382,   ["lower_discount"]=0,   ["cpfirmid"]="",   ["order_exchange_code"]="",   ["clearing_bank_accid"]="",   ["class_code"]="SPBFUT",   ["userid"]="",   ["tradenum"]=1982204382,   ["datetime"]={11},   ["liquidity_indicator"]=0,   ["kind"]=1,   ["ordernum"]=29666422467,   ["exec_market"]="",   ["repoterm"]=0,   ["extref"]="",   ["investment_decision_maker_short_code"]=0,   ["mleg_base_sid"]=-1,   ["value"]=56935,   ["waiver_flag"]=0,   ["client_code"]="-----------",   ["investment_decision_maker_qualifier"]=0,   ["lseccode"]="",   ["client_qualifier"]=0,   ["yield"]=0,   ["on_behalf_of_uid"]=0,   ["ext_trade_flags"]=0,   ["upper_discount"]=0,   ["repo2value"]=0,   ["system_ref"]="",   ["tech_center_comission"]=0,   ["executing_trader_short_code"]=0,   ["reporate"]=0,   ["order_num"]=29666422467,   ["exchange_code"]="",   ["price2"]=0,   ["settle_currency"]="",   ["order_revision_number"]=0,   ["flags"]=68,   ["cross_rate"]=0,   ["brokerref"]="CC trans_id=1 Sell",   ["sec_code"]="SiH8",   ["block_securities"]=0,   ["clearing_comission"]=0,   ["broker_comission"]=0,   ["bank_acc_id"]="", }, -- Table: {7} {   ["settle_date"]=20180305,   ["otc_post_trade_indicator"]=0,   ["period"]=1,   ["exchange_comission"]=0.8,   ["settlecode"]="T1",   ["qty"]=1,   ["local_time"]=31822.108,   ["capacity"]=0,   ["canceled_uid"]=0,   ["seccode"]="SiH8",   ["clearing_firmid"]="",   ["canceled_datetime"]={18},   ["account"]="-----------",   ["linked_trade"]=0,   ["side_qualifier"]=0,   ["client_short_code"]=0,   ["firmid"]="SPBFUT",   ["executing_trader_qualifier"]=0,   ["trade_currency"]="SUR",   ["accrued2"]=0,   ["trans_id"]=1,   ["repovalue"]=0,   ["order_price"]=0,   ["accruedint"]=0,   ["uid"]=29135,   ["start_discount"]=0,   ["station_id"]="",   ["order_qty"]=0,   ["price"]=56935,   ["trade_num"]=1982204382,   ["lower_discount"]=0,   ["cpfirmid"]="",   ["order_exchange_code"]="",   ["clearing_bank_accid"]="",   ["class_code"]="SPBFUT",   ["userid"]="",   ["tradenum"]=1982204382,   ["datetime"]={19},   ["liquidity_indicator"]=0,   ["kind"]=1,   ["ordernum"]=29666422467,   ["exec_market"]="",   ["repoterm"]=0,   ["extref"]="",   ["investment_decision_maker_short_code"]=0,   ["mleg_base_sid"]=-1,   ["value"]=56935,   ["waiver_flag"]=0,   ["client_code"]="-----------",   ["investment_decision_maker_qualifier"]=0,   ["lseccode"]="",   ["client_qualifier"]=0,   ["yield"]=0,   ["on_behalf_of_uid"]=0,   ["ext_trade_flags"]=0,   ["upper_discount"]=0,   ["repo2value"]=0,   ["system_ref"]="",   ["tech_center_comission"]=0,   ["executing_trader_short_code"]=0,   ["reporate"]=0,   ["order_num"]=29666422467,   ["exchange_code"]="",   ["price2"]=0,   ["settle_currency"]="",   ["order_revision_number"]=0,   ["flags"]=68,   ["cross_rate"]=0,   ["brokerref"]="CC trans_id=1 Sell",   ["sec_code"]="SiH8",   ["block_securities"]=0,   ["clearing_comission"]=0,   ["broker_comission"]=0,   ["bank_acc_id"]="", }, -- Table: {8} {   ["week_day"]=1,   ["hour"]=0,   ["ms"]=0,   ["mcs"]=0,   ["day"]=1,   ["month"]=1,   ["sec"]=0,   ["year"]=1601,   ["min"]=0, }, -- Table: {9} {   ["week_day"]=5,   ["hour"]=22,   ["ms"]=484,   ["mcs"]=484000,   ["day"]=2,   ["month"]=3,   ["sec"]=51,   ["year"]=2018,   ["min"]=26, }, -- Table: {10} {   ["week_day"]=1,   ["hour"]=0,   ["ms"]=0,   ["mcs"]=0,   ["day"]=1,   ["month"]=1,   ["sec"]=0,   ["year"]=1601,   ["min"]=0, }, -- Table: {11} {   ["week_day"]=5,   ["hour"]=22,   ["ms"]=484,   ["mcs"]=484000,   ["day"]=2,   ["month"]=3,   ["sec"]=51,   ["year"]=2018,   ["min"]=26, }, -- Table: {18} {   ["week_day"]=1,   ["hour"]=0,   ["ms"]=0,   ["mcs"]=0,   ["day"]=1,   ["month"]=1,   ["sec"]=0,   ["year"]=1601,   ["min"]=0, }, -- Table: {19} {   ["week_day"]=5,   ["hour"]=22,   ["ms"]=484,   ["mcs"]=484000,   ["day"]=2,   ["month"]=3,   ["sec"]=51,   ["year"]=2018,   ["min"]=26, },

Подтверждаю. Посмотрел сейчас логи последние и старые в том числе. В OnTransReply приходит ["brokerref"]="". А в OnOrder и в OnTrade приходит заполненным.

По логам на обоих версиях:
7.14.1.7, проверял 27.02.2018
7.16.2.5, проверял 02.03.2018

Сделки были по SiH8 за обе даты, в обоих направлениях по несколько штук.

Обязательно, завтра же позвоню Биллу Гейтсу, и лично попрошу переделать Windows под мои нужды...

Вы спросили, как будут устанавливаться Quik'и от разных брокеров, я вам написал. Перечитайте ещё раз более внимательно.

Вы у себя на компьютере нажмите Win+R, и в появившееся окно введите строчку «%APPDATA%», затем нажмите Enter.
В открывшимся окне проводника, увидите длинный список папок от всех программ, которые установлены на вашей машине.
Там в этой папочке можно найти и историю браузеров, и Skype звонков, и даже настройки всяких инструментов Яндекса.
Это такая специальная папка в профиле пользователя, куда пишут рабочие файлы приложения... так устроена система Windows.

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

А вот как раз ситуация, когда сами пользователи начинают настраивать ярлыки какие-то у себя, прописывать какие-то права, вот эта ситуация как раз и неправильная.
И вот именно в этом случае, как раз «пути пересекутся» и «ПО сразу же перестанет работать».

Всё же предлагаю вам хотя бы немного разобраться в теме безопасности ОС и в целом программировании приложений...

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

Понятно.

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

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

К сожалению, у этого способа есть недостаток. А именно, не работает обновление версий из Quik запущенного таким способом.
Выдаёт такую вот «прелесть»:


Понятно почему, потому что Quik запущен под обычным пользователем, и у него нет прав делать запись в системную папку программы в %ProgramFiles(x86)%.
Файлы же скачиваются в папку %APPDATA%\QUIK_ИМЯБРОКЕРА\spool\frontend. В итоге либо вручную делать резервные копии старой версии и вручную переписывать все файлы в %ProgramFiles(x86)%\QUIK_ИМЯБРОКЕРА, либо запускать под администратором Quik на время обновления, что неправильно.

Соответственно. В Quik (или даже в update.exe) необходимо добавить вызов UAC для поднятия привилегий на время обновления программы, с запросом пароля, как это обычно и делается.
Добавьте это к зарегистрированному ранее пожеланию.

Что вы мне предлагаете «пощёлкать» в Windows?... запускать сетевое приложение под админом, как некоторые горящие головы из тех. поддержки неких брокеров предлагают... за такие советы увольнять надо. А я с эти сталкивался уже не раз. И создаётся впечатление, что в тех. поддержках многих солидных банков работают какие-то недоучившиеся студенты, вообще не имеющие представление о том, что они делают.

Легко. Сейчас, когда вы ставите Quik от разных брокеров, то они ставятся в папки с разными именами %ProgramFiles(x86)%\ИМЯБРОКЕРА. То-есть:

%ProgramFiles(x86)%\QUIK_VTB24
%ProgramFiles(x86)%\QUIK_BCS
%ProgramFiles(x86)%\QUIK_FINAM

Туда же засунуты и рабочие файлы, чего делать нельзя. Их нужно переместить в папку %AppData%\ИМЯБРОКЕРА. Чтобы было два набора папок:

%ProgramFiles(x86)%\QUIK_VTB24
%ProgramFiles(x86)%\QUIK_BCS
%ProgramFiles(x86)%\QUIK_FINAM
%AppData%\QUIK_VTB24
%AppData%\QUIK_BCS
%AppData%\QUIK_FINAM

Вот и всё. Именно так это и должно быть по правилам сертификации приложений для Windows с точки зрения безопасности! Ссылки я приводил выше.
И именно так у меня сейчас настроено вручную через ярлыки запуска. А  должно настраиваться по умолчанию без дополнительных действий со стороны  пользователя.
Тем более, что настройка через ярлык — половинчатое решение, и оно не работает при обновлении программы на новую версию. Так как в Quik нет вызова UAC. См. ниже в сообщении.

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

Под «рыночной ценой» вы что здесь имели ввиду?

«вершина стакана» — это где?

Кто платит деньги маркет-майкеру и как он это делает «ответные движения»? расскажите поподробнее...

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

Я уже выяснил, что вместо поля COMMENT, нужно использовать поле CLIENT_CODE при посылке транзакции, и это поле не совпадает с полем CLIENT_CODE в ответах в колбэках, а приходит в виде поля BROKERREF... Это гениально!
Но всё же, могу ли я в Lua послать KILL_ALL_ORDERS c полем COMMENT, чтобы снять группу заявок предварительно отправленных с тем же полем COMMENT?

А вы говорите, что в Lua это поле COMMENT вообще игнорируется... зачем тогда такой пример давать? и для чего вообще эта строчка кода?

в примере \quik_lua\examples\test_trans.lua используется поле COMMENT, в которое прямо так и пишется строчка "LUA"

transaction.COMMENT = "LUA ".. tostring(x)

Осталось только узнать, что такое «групповое снятие заявок»?... Забавно, что поиск по документации Quik ничего не даёт. А поиск в Яндексе в первой же страницей выдаёт «Групповые заявки в КВИКе — Нет такого»...

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

В вашем примере из документации: https://arqatech.com/upload/iblock/194/quik_lua.zip

Да нет никакого цирка... а если есть, то докажите. В ленте вы видите того, кто был последний, а не того, у кого меньший объём.

Совершенно верно. Тоже самое сформулировано в других терминах. Если в торговой системе уже есть заявка (то-есть она была первой), а ваша приходит после неё (то-есть она была последней), то направление сделки будет по вашей заявке.

Всё, я понял откуда приходит это поле brokerref. Нужно либо вручную через окошко Ввод заявки, заполнить поля «Код клиента» и «Поручение» чем-нибудь. Либо из Lua скрипта заполнить поле CLIENT_CODE чем-нибудь при sendTransaction.

Единственно, непонятно куда девается содержимое поля COMMENT при sendTransaction. Я нигде не вижу в колбеках значения из этого поля.

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

Чтобы Quik соответствовал минимальным требованиям безопасности для приложений Windows. Когда вас взломают, поймёте это...
Настройка хранения рабочих файлов в папке профиля пользователя %AppData%\Quik не имеет отношения ни к брокеру, ни к установщику.
Это настройка, которая должна быть внутри Quik.exe... также как настройка пути к *.wnd файлам.
Примерно вот так: