Андрей (Все сообщения пользователя)

Я имел ввиду lua_share.
А по теме - так да, написал, чтобы добавили пожелание на доработку.
А по хорошему надо их в отдельный класс переносить.

А вы тот самый Антон? )
Нет, вроде его там нет и нужно добавить.

А теперь вопрос про еще один признак - структурированный продукт. Для облигаций. Как получить в lua?  

У меня с помощью этой библиотеки скрипт одного терминала, где глубина стакана только 20, максимально оперативно запрашивает стакан в другом терминале, где он 50 )  

Это действительно может быть связано с вылетом терминала. Пару раз именно рядом происходило.
Я же после нашего такого плотного обсуждения lua_share, написал свою библиотеку общей памяти на с++ ) Между терминалами, но без отдельного сервера. С синхронизацией на уровне отдельных объектов. Подпиской на их изменения в общей памяти, локированием.. С многопоточностью, в т.ч. возможностью из скрипта запускать выполнение lua-ф-ции в отдельном потоке (в этом же луа стейте).. Всё как хотел ) Но вот, иногда во время сильной интенсивности на бирже терминал слетает. Однако, это лишь помогает нам понять, что ошибка в нем все же есть. И нет, в этом скрипте я не использовал свою многопоточность. Все же, хочется дождаться ответа разработчиков насчет кеширования подключаемых модулей не внутри одного lua инстанса, а между разными скриптами и их повторными запусками.

С чего это така яуверенность? ) Смотрите. Если в квике ошибки нет, то запуски скриптов не должны иметь side effects на последующие запуски. А я вижу, что все скрипты остановлены и запуск приводит к такой проблеме. Как вы можете это объяснить, если в квике нет ошибки? И нет смысла говорить о простом примере, т.к. у меня самого он не воспроизведет проблему на свежем запуске квика. А каким примером привести квик в такое проблемное состояние я, конечно, не знаю. Поэтому надо копать с другой стороны - чтобы разработчики посмотрели у себя, почему вообще возможны такие side effects с подгрузкой модулей. Какое-то там кеширование. Потому я и дал такую наводку сразу.

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

Я описал ситуацию на простом примере. Да, общий код модуля не исполняется. Можно в нем написать message('hello') и это не будет напечатано. Но, как сказал, не всегда. Не знаю что приводит к проблеме. Обычно каждый перезапуск макроса корректен - будет напечатано hello. А потом перестает. Проблема есть.

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

Пока эта ошибка так и не исправлена. Когда планируется?

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

Не знаю что служит причиной, но сталкиваюсь с тем, что при перезапуске скрипта  require как бы работает в холостую. Не исполняя код модуля. Как будто кто-то до этого уже загрузил этот модуль (хотя package.loaded его не содержит до require, получает после). Но это же самое начало скрипта, а другие скрипты не должны на него влиять. Это вроде как разные "машины". Может как-то ошибочно остается "полуподгруженным" от предыдущего запуска этого же скрипта?
Лечится перезапуском всего квика.

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

Во первых для того, что, как минимум, исключаются раундтрипы между клиентом и сервером квик, а это уменьшает общую задержку. Сервер "на коротке" общается с биржей. А вы замерьте, какой % от текущего сетевого ожидания занимает этот путь сервер-биржа. Далее, конкретно, вы ждете onTransReply на KILL_ORDER? Я попросил ответить максимально точно и детально, какого технического сигнала вы ждете. Тут справедливо замечают, что реплай приходит иногда и долше обычного. А перемещение ордера мышкой работает быстрее. Посмотрите точнее данную реализацию. Так же замечу, что реплай на KILL_ORDER почти всегда успешен. Можно было бы и подумать, как оптимизировать и допускать авансом разблокирование лимита. Но ладно, это отдельная тема, пока не об этом. А о том, что внутренние механизмы сигналов (даже не колбеки lua) и обработка связки удаление+создание на сервере дали бы, уверен, неплохое уменьшение задержки.

Эмулировать - значит дать пользователю 1 вызов API, а в нем инкапсулировать KILL_ORDER и NEW_ORDER, с правильной и оптимальной реализацией ожидания между ними. Вот у меня вопрос - как в точности реализовано перемещение ордера мышкой в стакане? Вы понимаете, что я спрашиваю про паузу между KILL_ORDER и NEW_ORDER по большей части. Там самая оптимальная реализация?

Надо, Федя.. надо..
Вполне простая вещь - передвинуть заявку. Для клиента это по смыслу одна операция. Даже чисто технически это сложно сейчас сделать, разбивая на стадии, ожидая колбеки после снятия.. Ожидание разблокирования лимитов при KILL_ORDER можно и нужно оптимизировать. Как минимум в рамках вот такой пары - снятие+создание. Которую можно реализовать эмуляцией MOVE_ORDERS.

Или вы про колбек OnMoneyLimit? Я не измерял насколько он раньше, чем 1й onTransReply, но экспериментально видел, что за 50мс отправлять создание не получается.
В любом случае связку снятие+создание (оптимизация расчета лимитов) можно и полезно реализовать, раз разработчики говорят, что снижекние задержки является приоритетом.

Это не должно требовать прямого доступа на биржу )

100-300 это до первого onTransReply по trans_id KILL_ORDER. А ваши события можно получать как-то иначе? Если нет, то очевидно, что ничего быстрее событийная модель не обеспечивает. Зачем мириться, если все достижимо, надо только доработать алгоритм снятия лимитов при KILL_ORDER. Чтобы не ждал лишнего от биржи, а делал это авансом, грубо говоря. Всё там возможно. А иначе дело даже не в "на всю котлету". В первом сообщении я писал про ошибку изменения ордера продажи своих, не маржинальных, акций. В шорт их не дают. Соответственно, даже при свободных лимитах, переставить не получается. Без доплаты - а что тут прикольного? Это очевидная вещь - оптимизировать связку снятие+создание как единую логическую операцию.

Как MOVE_ORDERS в режиме 1 и с 1 заполненной заявкой из двух.

О снятии 2 речи не идет. Мы про снятие+создание с оптимизацией контроля лимитов в этой операции.
Указанные особенности MOVE_ORDERS понятны и ничему не противоречат.

В идеале предлагаю реализовать эмуляцию типа транзакции MOVE_ORDERS в системе QUIK, раз этого нет в биржевом интерфейсе. Это можно реализовать куда оптимальнее на вашей стороне, чем 2 транзакциями как сейчас. Или как минимум сделать учет снятия мгновенным и действующим для последующих NEW_ORDER. Можно для этого как-то отдельно оформить вызов, если не хотите менять текущий механизм. Но это уже будет инструмент.

Событийная модель и приводит к тому, что создание ордера требует паузы в 100-300мс после снятия. Надо думать как обеспечить функционал, аналогичный MOVE_ORDERS срочного рынка. Почему там это есть, а здесь нет?

"Заявки с разными ценами, так что средств от первой заявки может не хватить на вторую, так что проверка достаточности средств необходима." -
ок, пусть проверяется, но уже с учетом снятия исходной суммы. Это я и имел ввиду в п.2.

"Потому как сервер QUIK в данном случае - единственная проверка достаточности средств в случае фондового рынка.
С точки зрения биржи (для фондового рынка) все операции выполняются на счете брокера, на весь лимит брокера."
Тогда я не совсем понимаю, чего ждет сервер QUIK от биржы на клиентский KILL_ORDER.

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

Когда речь о двух транзакциях NEW_ORDER - все понятно. Но когда это по смыслу одна транзакция типа MOVE_ORDERS, которую приходится технически реализовывать двумя (KILL_ORDER, NEW_ORDER) - требуется доработка для этого особого случая. Чтобы эти транзакции можно было подавать одну за другой без паузы и это не приводило к вышеописанным проблемам с проверкой на сервере Quik.
Сходу приходят 2 пути решения:

1) Сделать вторую версию ф-ции sendTransaction, которая пропускает "проверку достаточности средств на сервере", идет сразу на биржу. Таким образом отправленные 2 транзакции обработаются без проблем, если прийдут на биржу в таком же порядке. Это уже достаточный уровень функционала. В худшем случае биржа просто не обработает вторую транзакцию, Ведь ваша проверка на сервере Quik - это как пре(дварительный)фильтр. Без него ничего страшного тоже не произойдет - получим отказ от биржи в реплае. Порядок будет практически обеспечен малейшей ручной задершкой в скрипте (много меньше текущих 100-300 мс).

2) Сделать проверку на сервере Quik более умной. Когда она получает KILL_ORDER, она уже обновляет предварительно допустимый лимит, чтобы последующая NEW_ORDER прошла проверку не дожидаясь ответа биржи на KILL_ORDER. За исключением вырожденных случаев, KILL_ORDER всегда исполняется биржей, поэтому такая оптимизация ожидания ответа на него - оправдана. Повторюсь, поскольку это префильтр, то его роль не критична. В худшем случае получим отбой от биржи вместо отбоя от сервера квик. Но зато обеспечим указанное эффективное редактирование ордера.

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

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

На вкус и цвет роботы у всех разные ) Естественно иногда нужно передвинуть заявку максимально быстро. Не дожидаясь реплая на удаление. Так что нужна ф-ция отправки транзакции в "экспертном режиме", без локальных проверок. Когда программист знает, что делает. Задержку между удалением и созданием он будет делать сам через sleep при необходимости.

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

Это новость про либо обе, либо ни одна. Об этом хорошо бы написать в документации.
Насчет направления и "из таблицы заявок по данному номеру":
На момент onTransReply нет еще onOrder и записи в заявках. Но в onTransReply есть почти вся смысловая информация о новой заявке. Не хватает только направления и именно для MOVE_ORDERS. И тогда не нужно вести свою базу заявок, ожидающих подтверждения. Ради этого одного поля.

Еще вопрос. Чем обусловлено наличие MODE=0 и MODE=1? Неужели неизменность количества позволяет как-то по особому, заметно эффективнее и т.п. релизовать? Настолько, что даже выделили отдельный режим, а не в рамках частного случая с заданием кол-в MODE=1.

1) Нужно по реплаю однозначно понимать статус по обеим заявкам (по отдельности).
2) Добавьте тогда как минимум эти поля по второй заявке (если она есть): sec_code, price, quantity, order_num.
3) Желательно добавить сюда и направление заявок. Даже если этого нет в биржевом интерфейсе, там нет и многих других полей, которые есть в реплае. Вы обогощаете ими. Так включите сюда же и направление 0\1. Например битом, по аналогии как оно заполняется для обычных транзакций (см выше). Но теперь это нужно тоже по обеим заявкам в одном реплае. Поэтому может и отдельным полем сделать. И дублировать его как все вышеуказанные в п.2 для второй заявки, если она есть.

Послушайте, мы тут делаем предложения по улучшению, а вы даете ответы в стиле "этого нет и такого функционала не предусмотрено". Я вам говорю, что он нужен и легко реализуем.
1) Признак направления заявки есть в самой заявке и он не меняется. Ничто не мешает для унификации его проставлять во flags так же, как для других транзакций. Чтобы в реплае понимать, реплай это на покупку или на продажу. Польза этого сомнений не вызывает, стоимость реализации низкая.
3) В описании про заявки, да.
Перестановка заявок на рынке FORTS выполняется по следующим правилам:

• Если MODE=0, то заявки с номерами, указанными после ключей
  FIRST_ORDER_NUMBER и SECOND_ORDER_NUMBER, снимаются. В торговую систему
  отправляются две новые заявки, при этом изменяется только цена заявок,
  количество остается прежним;
  
• Если MODE=1, то заявки с номерами, указанными после ключей
  FIRST_ORDER_NUMBER и SECOND_ORDER_NUMBER, снимаются. В торговую систему
  отправляются две новые заявки, при этом изменится как цена заявки, так и
  количество;
  
• Если MODE=2, то заявки с номерами, указанными после ключей
  FIRST_ORDER_NUMBER и SECOND_ORDER_NUMBER, снимаются. Если количество
  инструментов в каждой из снятых заявок совпадает со значениями, указанными после
  FIRST_ORDER_NEW_QUANTITY и SECOND_ORDER_NEW_QUANTITY, то в торговую систему
  отправляются две новые заявки с соответствующими параметрами.
  

Что же тогда считается успешной одной транзакцией, если успех принятия заявок может быть различным? И, как сказал, информативности в реплае максимум наполовину. OnOrder ему не замена, он может и не прийти. В такой ситуации механизм sendTransaction(MOVE_ORDERS) + onTransReply явно недоработан. Продумайте как полноценно доносить информацию в реплае. Мое предложение - отправлять 2 реплая, с еще одним битом во флаге с указанием на какую заявку из двух каждый. Обоснуйте, почему это не будет улучшением.

И судя по описанию происходит именно 2 транзакции на бирже. Причем может и только одна из них сработтать.

1) Код здесь будет лишним. Просто делаю { ACTION = "MOVE_ORDERS", MODE = '1',.. }., Ордер переставляется. А в колбеке flag имеет не праильный признак направления (покупка\продажа). За это отвечет вот такой бит (tr.flags>>17&1) у вас.Он не корректен для MOVE_ORDERS.

3) Очень странные вещи вы говорите. А как же тогда интерпретировать все поля OnTransReply(TABLE trans_reply) ? Они расчитаны на передачу данных по одному ордеру данной транзакции. Например order_num.

А собственно ордер и не меняет ориентацию. Если цена перешагивает барьер, он просто исполняется по рынку. Так что направление в onTransReply однозначно определено.

Пробую такие транзакции на срочном рынке в MODE=1.

1) в OnTransReply перестал работать бит, определяющие куплю или продажу - (tr.flags>>17&1). В ответе на NEW_ORDER это работает. Просьба доработать. Уверен, при перестановке цены на данном этапе уже известно, купля это или продажа. Если нет, просьба не оставлять его незаполненным, а копировать из перемещаемого ордера. Считая по умолчанию, что ордер не меняет свою "ориентацию". По умолчанию это лучше, чем пустое поле.

2) Если SECOND_ORDER_NUMBER = nil , то, по хорошему, сервер должен игнорировать SECOND_ORDER_NEW_PRICE и SECOND_ORDER_NEW_QUANTITY, даже если они заполнены. Но есть подозрение, что они могут переопределять соответствующие FIRST в этом случае.. Прошу разъяснить.

3) Если заполнены все поля FIRST и SECOND, то должно прийти 2 OnTransReply? Это вообще просто способ сократить кол-во sendTransaction, а так эти поля совершенно независимы и аналогичны 2м sendTransaction (для MODE=1)?

А может и сорцами поделитесь?

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

Может вы тоже подскажете, как это делается обобщенно через win32 ф-ции библиотеки w32 конкретно для стакана? Название активного окна (стакан) и выделенная в стакане строка. И как в макросе ожидать нажатие клавиш.

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

Еще наткнулся на странное сообщение "Нужно следить за UID экземпляра QUIK, чтобы фильтровать "чужие" заявки.". Это еще актуально? Действительно ли могут прийти колбеки заявок других клиентов? Я то предполагал это поле либо 0, либо правильным..

Какой правильный формат CLIENT_CODE , если 123456/345 не работает? 345 - это доп данные  

Он всегда есть в OnOrder, ореде с т.з. елиента. Вы хотите сказать, что вы не можете своими внутренними признаками определить, ручной ордер или нет? Чтобы для ручных возвращать trans_id не так же, как для незаполненных. Ну исторически уже привыкли к 0 для ручных, а для незаполненных тогда просто не возвращать поле (=nil). Из ваших слов про биржу не следует, что вы не можете так формировать свои поля в OnOrder.

И насчет CLIENT_CODE в транзакции. Я его заполняю своим номером. Как его получить в OnOrder? Там нет такого поля, есть похожее по описанию brokerref, но оно не содержит моих данных, а именно /код клиента.

Приведите пожалуйста полный список полей транзакции, которые входят и в ордера и в биржевой протокол и, значит, заполнены в каждом пришедшем OnOrder.
А свои дополнения можно сделать как пишу выше, чтобы не было неразберихи. Либо =nil (отсутствуют в пришедшем ордере), либо -1, пока вы не вставите истинное значение.  

А вы уверены, что он будет проставлен в этом первом пришедшем OnOrder, в котором даже trans_id  не проставлен? Не думаю.. т.к. транзакция еще не обработана.
И в любом случае это bad design, о чем я выше пишу, когда не заполненное поле имеет значение, валидное для заполненного. И исправить это не сложно без потерь производительности, нужно сделать.

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

ну или особое исключение trans_id=-1 или nil, пока не заполнено, в конце концов )

если такого признака пока нет, можно назначить некий бит флага под это дело, например. Который =1, если trans_id имеет финальное значение. Вобщем варианты есть, чтобы не тормозить независымые потоки.

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

Так он становится неотличим от заявки, которую вводишь руками. Поэтому давайте все же зарегестрируем пожелание, чтобы onOrder не рассылался раньше, чем на сервере обработается в полной мере транзакция, назначится trans_id. И все пришедшие ОnOrder будут с верными trans_id (как и order_num). А уж какие-то прочие поля можно досылать потом.

Потому как без trans_id обрабатывать его осмысленно невозможно. Это не хорошо.

Добавлю еще по этому поводу. Иногда, редко, OnOrder по созданию заявки приходит еще один самый первый раз, даже раньше OnTransReply, причем с trans_id=0. Речь про заявки из макроса, которым я назначаю trans_id. Как говорилось ранее, да, OnOrder дублируется несколько раз после OnTransReply. С изменениями в поле uid кажется. Но вот такое, что он приходит еще раз раньше OnTransReply.. не ожидано было. Не ошибка ли?