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

точно ли код класса указан верно?
Такой класс есть только на нашем демо контуре, у брокеров нужно указать TQBR

Для заявок OrderNum+ClassCode+TradeDate
Для сделок TradeNum+Operation+ClassCode+TradeDate
Для обезличенных сделок TradeNum+ClassCode+TradeDate+SecCode

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

Старатель,
Уже был развернутый ответ

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

Старатель,
К сожалению в ответе произошла ошибка.
Заявки не могут быть с совпадающим номером на одном классе.
И SECCODE на транзакции KILL_ORDER не нужен.
И в Lua тоже. Почему у автора не получилось снять заявку не понятно.
На самом деле номер в разрезе инструмента может совпадать только на обезличенных сделках

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

Проблема изучается. Постараемся в ближайшее время дать ответ.

Речь была именно про запрос на сервер. те запрос к серверу, сколько есть на сервере в такой-то таблице.

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

Мы же договорились что getServerNumberOf вернет данные в момент запроса. Хотите запрашивайте ДО описания параметров таблицы Торговые счета, хотите после. Вам уже решать


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

Если второй шлюз подключился, и засылает те же бумаги что и первый, с теми же фирмой и счетом, значит у пользователя УЖЕ есть нужные лимиты (получил при первом шлюзе) и условие сработает т.к. грузить просто ничего не надо.

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

Если счет и фирма та же, но бумаги другие, значит либо будет лимит по новым бумагам (условие не сработает), либо лимитов вообще нет и не будет (это допустимо т.к. ранее уже был лимит с нужным счетом).

ответ УЖЕ был:

Ошибаетесь.
Если лимит есть на сервере, но еще не загружен в терминал то условие НЕ выполнится и getNumberOf("depo_limits") покажет МЕНЬШЕ чем getServerNumberOf("depo_limits").


Ошибаетесь.
Раз данные получены с сервера, значит либо лимит есть и тогда Вы его увидите в depo_limits.
Либо лимита нет, просто нет, а не "еще не загружен".

Mixa,
Пожелание уже было зарегистрировано (см соседнюю ветку).

И что это меняет? Пожелание было зарегистрировано с оговоркой чтобы гипотетическая функция getServerNumberOf будет работала для всех таблиц из списка getItem, в том числе и trade_accounts.
Таким образом, Вы сможете проверить наличие прав при условии что getServerNumberOf("trade_accounts") == getNumberOf("trade_accounts")
т.е. после того как (getServerNumberOf("depo_limits") == getNumberOf("depo_limits")) и (getServerNumberOf("trade_accounts") == getNumberOf("trade_accounts")), проверяем по trade_accounts наличие прав на нужный класс и ищем в depo_limits нужный лимит, уже уверенные что данные получены с сервера.

Ваше пожелание зарегистрировано. Мы постараемся рассмотреть его и сообщить Вам результаты анализа. Впоследствии, по результатам анализа, будет приниматься решение о реализации пожелания в будущих версиях ПО.

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

Для того чтобы снять стоп, параметр TRANS_ID вообще не нужен.
В транзакции на снятие стопа есть только номер стоп заявки, это НЕ тоже что TRANS_ID.

TRANS_ID - Нужен исключительно Вам т.е. Вашему роботу. QUIK на него вообще никак не смотрит.
Нам не известно какая логика заложена в Вашем роботе, следовательно не можем ответить на вопрос о его поведении.

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

UNIX TIME - это просто количество секунд начиная с какой-то даты (1 января 1970г).
можно получить через тот же os.date
Судя по всему, Вам не это нужно.
Просто сами определите для себя какое число Вам требуется и сгенерируйте. тех поддержка в этом месте не причем.
Вопрос только и только на Вашей стороне.
Хотите, считайте тот же UNIX TIME но с 2000 года
или "сожмите" дату до нужного размера (например сложив чила)
Или другие варианты которые Вам понравятся.

Определите самостоятельно, это не так трудно.

Еще раз. Если количество строк в таблице терминала равно количеству строк на сервере, это УЖЕ факт того что данные загрузились.
Какие данные? Вы УЖЕ можете проверить т.к. есть факт что они загрузились.

А Вы понимаете, что Вам уже несколько раз было предложено?
И в чем разница:
"если количество строк в таблице = количеству на сервере, значит данные загружены, а раз нужных данных в таблице нет, значит их действительно нет.

??
Докажите что Ваше предложение хоть чем-то отличается от нашего?
разница только в том что наше в разы проще в реализации.

Выше было сказано, цитата:
Ситуация:
Запись {Firm2 = {D, E}} в trade_accounts есть, значит права есть. И это точно.
флаг, что все данные в таблице загружены получили.
Нужного лимита среди данных нет, значит его просто нет (брокер не загрузил)

Это легко проверить самостоятельно

У нас нигде нет никакой структуры определяющей строгость загрузки тех или иных данных.

Иван,
Дополним,
судя по всему вопрос не технический, а логический. Нам не важно что вы напишите в TRANS_ID, главное чтобы размер был не больше «2 147 483 647»

Вы сами решите для себя нужна ли Вам вообще os.date("%d%H%M%S"), может ее не надо там указывать и все?
если нужна, сами для себя решите зачем, может там достаточно краткого формата ДДММГГ

Если вопрос в том, как в os.date указать выходной формат, то ответ есть в документации на Lua

Иван,
Вы же сами сказали что от «1» до «2 147 483 647»
В чем сложность сгенерировать число входящее в этот диапозон не понятно.
Если хочется получить его из даты, тот же UNIX TIME вполне в него влезает

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

Mixa,
По сути Вы хотите две разные вещи. Флаг загрузки данных (его нет) и флаг наличия прав (уже есть в trade_accounts).
Вы же всеми силами пытаясь объединить два разных флага в одну функцию по косвенным признакам. А это вызывает вопросы и примеры трудности реализации.
Проще говоря, возникает слишком много разных "если".
Предложенный пример не будет надёжно работать т.к. наличие прав не всегда равно наличию данных.

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


В данном конкретном примере функция isLimitsLoaded вообще не нужна, и даже "Флаг загрузки данных" не обязателен, хотя его можно было бы добавить при желании:

После подключения первого шлюза сервер сверяет транслируемые классы с правами пользователя и отправляет клиенту trade_accounts в которой уже есть данные вида {Firm1 = {A, B}}
Пользователю приходят лимиты по бумагам, содержащимся в классах A и B, в т.ч. по бумаге X. Как обычно,  в этой части никаких изменений не требуется!
Пока лимиты грузятся можно было бы добавить проверку "Флаг загрузки данных".
Но в trade_accounts нет {Firm2 = {D, E}}, поэтому скрипт ждет.

Далее запускается второй шлюз.
И клиенту транслируются лимиты по бумагам D и E. Поскольку лимиты по бумаге X уже были раннее загружены, то повторно не транслируются. Все как обычно,  в этой части никаких изменений не требуется!
Клиент уже может проверить наличие {Firm2 = {D, E}} в trade_accounts
Если есть  =>  Лимиты по бумаге X  загружены (скрипт может это проверить в таблице лимитов), можно торговать в  классе E.

Ваше пожелание зарегистрировано. Мы постараемся рассмотреть его и сообщить Вам результаты анализа. Впоследствии, по результатам анализа, будет приниматься решение о реализации пожелания в будущих версиях ПО.

_sk_,
Если права одинаковые, тогда да.

Конечно нет, это исключено. Только брокер может видеть заявки других клиентов.

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


Да, сервер проверяет права на классе. Фирма счет (код клиента) и отправляет клиенту те лимиты которые им удовлетворяют.
Что это даст не понятно.
Например на СПБ американские бумаги, на ФР российские, права одинаковые, лимиты разные. В результате только проверки прав недостаточно.

Cервер так и делает, было же сказано что если прав нет то и лимитов нет.

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

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


Да brokerref, там должен быть комментарий. Проверьте еще раз.

Никто не говорил про повторную загрузку.
Говорилось про проверку доступности, а не загрузку. Это не одно и то же.

По сути это и есть "повторная проверка доступности", разве нет?
И как уже было сказано, trade_accounts это как раз и есть проверка прав по firmid + class_code и Вы сами сказали что задачу это не решает.

К сожалению, наш внутренний регламент не разрешает связь клиента с разработчиком.

Еще раз, trans_id это наш параметр, его в принципе никогда нет в ордере. Наш сервер его проставляет, а не биржа.

Это описано в биржевом протоколе, который не является тайной.
описание на сайте биржи:
http://ftp.moex.com/pub/ClientsAPI/ASTS/Bridge_Interfaces/Equities/Equities3­8_Broker_Russian.htm

К сожалению разговор уже идет по кругу.
Никак нельзя определить что лимиты загружены по firmid + class_code.
Просто нет и все.
Дорабатывать как то сервер ради этого нецелесообразно, значит работать только с тем что есть.
А того что есть недостаточно, альтернативный вариант Вас не устраивает.
Итого задача не решаема а значит считается закрытой.
Ок?

CLIENT_CODE - это биржевой параметр. Вы отправляете транзакцию на биржу и в OnOrder приезжает тело заявки с биржи, включая CLIENT_CODE.



Мы не можем что-то добавить в биржевой протокол, только биржа это может.
Добавить свои собственные параметры, да можем, и UID и trans_id мы как раз и добавили.
Добавить к ним еще один? Зачем он ведь будет работать точно так же. И с ним будут точно такие же проблемы.

От чего же, Вы хотели
таблица trade_accounts ровно это и покажет.
Да она не показывает именно лимиты, но Вы сами же сказали что это и не требуется
Ок, смотрите trade_accounts
Если там нет нужной "firmid + class_code" значит и лимитов по ним нет. И это точно.
Если есть, значит лимиты есть, потому что запись там не появится пока не будет получен лимит по любой бумаге связывающей фирму+счет+код клиента.

Нет, лучше trade_accounts (Торговые счета), там есть связка фирма+счет+список классов

Тогда смысл в чем? Смотрите колбек OnFirm или таблицу firms, там правда нет класса, есть торговая площадка (по сути рынок). Вот Вам и isLimitsLoaded

Еще раз.
Лимиты не привязаны к классам.
Есть лимит, в нем фирма и инструмент, класса нет.
Как по Вашему, сервер должен понять по  firmid + class_code что например лимит по LKOH из TQBR должен вернуть true, при условии что лимит уже был отправлен в EQRP_INFO?
Допустим, для первого класса EQRP_INFO все понятно, сервер может его запомнить при первой отправке и функция сработает.
Но как он должен понять что по TQBR тоже должен вернуть true? только если залезет в "отправленные" и еще раз проверит лимит по LKOH на доступность.
"Доступность" это ведь не только фирма и класс, но и инструмент же. Если какой то инструмент снимут с торгов (со всех классов), сервер не отправит лимит.
Получается серверу придется выполнить одну работу уже два раза. А у брокера миллионы, десятки миллионов, лимитов по 236 классам и это только ФР. Представьте как север будет их все проверять.

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

Не сработает, потому что лимиты уже были отправлены при появлении EQRP_INFO

Это можно исправить только если сервер будет помнить для каждого лимита весь список классов. Чтобы можно было в функции указать любой класс. Не так ли.
Еще раз цитата:

Еще пример, есть класс EQRP_INFO, и есть классы TQBR, SMAL, во всех трех классах есть одинаковые инструменты.
НО, класс EQRP_INFO транслируется отдельным шлюзом. По Вашей логике, сервер должен отправить Вам только класс EQRP_INFO, а про TQBR, SMAL вообще ничего не сказать.
Так? И что Вам это даст? Вы же торговать явно не в EQRP_INFO будете.
Еще пример. Сегодня брокер загрузил EQRP_INFO раньше TQBR, SMAL, и Вы в коде напишите isLimitsLoaded(firmid, "EQRP_INFO") и оно сработает. А завтра брокер возьмет и поменяет расписание запуска шлюзов (а почему нет) и Ваш код сломается.

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

Можете самостоятельно указать признак в комментарии, см параметр CLIENT_CODE

В readme сказано:

Не должен.
Потому что:

И про это тоже, было сказано:

Еще раз.
На ФР и СПБ, МОГУТ быть одинаковая фирма счет и код клиента.
Как этот факт может дать однозначный ответ? Конечно никак.

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

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

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


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

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

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

Нет, причины уже были озвучены.
Фирма может быть одна на все рынки.
Счет в большинстве рынков да разный, но не на всех, на том же СПБ и ФР они могут совпадать.
Итого, может быть ситуация когда фирма и счет одинаковы на ФР и СПБ.
Например Вы хотите торговать российскими бумагами на ФР, но Ваша функция покажет true по лимитам иностранного рынка СПБ, как быть?

Сервер отправляет клиенту количество строк в таблице с лимитами, а потом отправляет сами лимиты.
Запустили еще шлюз. Сервер отправляет клиенту новое количество строк в таблице с лимитами, а потом отправляет сами новые лимиты.

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

К чему?

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