Владимир, Как уже было сказано у нас тикет не повторяется В связи с не однократным отказом в сотрудничестве, делаем заключение что дальнейший анализ не представляется возможным. Тему считаем закрытой.
Stanislav Tvorogov написал: Мы рассмотрели Ваше пожелание. По итогам его анализа сообщаем Вам, что мы также считаем целесообразным его реализацию и постараемся включить в план доработок при выпуске одной из следующих версий нашего ПО.
Доброго здоровья, Станислав!!! Подскажите, предложения реализованы? С какой версии рабочего места? В каком файле находятся настройки соединений? У меня версия 7.25. В ней уже реализовано слежение за соединениями с серверами?
Яна написал: Коллеги, изменилось ли что-то с момента последнего ответа? Очень нужен нормальный API к квику.
Выпуск такого API не планируется, потому что уже есть FIX приборы.
Цитата
Яна написал: Кстати, у ИБ даже курс по программированию на их API выложен, поэтому нам бы тоже такое не помешало. Безусловно за такой курс готов заплатить.
Для заявок OrderNum+ClassCode+TradeDate Для сделок TradeNum+Operation+ClassCode+TradeDate Для обезличенных сделок TradeNum+ClassCode+TradeDate+SecCode
на сделках (не обезличенных) нумерация на разных инструментах одного класса не совпадает. Да это значит что номер одной сделки в обезличенных, и в обычных, может быть разным
Старатель, Речь о некоторых зарубежных шлюзах, где номер обезличенной сделки может быть один на разных инструментах одного класса. В свое время, из-за этого SecCode был добавлен в список первичного ключа таблицы AllTrades в модуле экспорта биржевой информации.
Старатель, К сожалению в ответе произошла ошибка. Заявки не могут быть с совпадающим номером на одном классе. И SECCODE на транзакции KILL_ORDER не нужен. И в Lua тоже. Почему у автора не получилось снять заявку не понятно. На самом деле номер в разрезе инструмента может совпадать только на обезличенных сделках
Mixa, Вам уже было сказано что согласование с разработчиком возможно исключительно только после регистрации пожелания. Пожелание зарегистрировано, информация ушла разработчикам, ждите ответ.
Mixa написал: Пока не будет получено новое значение "доступных лимитов на сервере" с нового шлюза, условие getServerNumberOf("depo_limits") == getNumberOf("depo_limits")будет выполняться.
Вы боитесь что сервер подсчитает сколько лимитов отправить пользователю с задержкой, т.е. пользователь получил класс и право им торговать, но сам сервер еще не одумался есть ли у пользователя лимиты? Такая ситуация невозможна, если бы она существовала то это была бы дырень в безопасности.
Mixa написал: Для этого надо гарантировать, что сервер отправит количество доступных на сервере лимитов ДО описания параметров таблицы Торговые счета.
Мы же договорились что getServerNumberOf вернет данные в момент запроса. Хотите запрашивайте ДО описания параметров таблицы Торговые счета, хотите после. Вам уже решать
Цитата
Mixa написал: В противном случае, getServerNumberOf("depo_limits") = N и getNumberOf("depo_limits") = N
Не доказано. Вам уже было сказано что лимиты НЕ привязаны к классам, это можно читать так что лимиты НЕ привязаны к шлюзам (исключение только срочный рынок)
Если второй шлюз подключился, и засылает те же бумаги что и первый, с теми же фирмой и счетом, значит у пользователя УЖЕ есть нужные лимиты (получил при первом шлюзе) и условие сработает т.к. грузить просто ничего не надо.
Если фирма или счет отличаются, значит условие не сработает, значит есть еще лимиты и другого быть не может. Нет и не может быть такой ситуации при которой по счету нет ни одного лимита. Т.к. связка между счетом и кодом клиента происходит именно через лимит по бумаге. Так что если второй шлюз пришлет другие фирму и счет, то лимит совершенно точно будет и условие не сработает.
Если счет и фирма та же, но бумаги другие, значит либо будет лимит по новым бумагам (условие не сработает), либо лимитов вообще нет и не будет (это допустимо т.к. ранее уже был лимит с нужным счетом).
Mixa написал: Но и getServerNumberOf("depo_limits") == getNumberOf("depo_limits") = N -- выполняется Хотя лимиты со второго шлюза могут быть еще не загружены!
ответ УЖЕ был:
Цитата
Sergey Gorokhov написал: Если лимит есть на сервере, но еще не загружен в терминал то условие НЕ выполнится и getNumberOf("depo_limits") покажет МЕНЬШЕ чем getServerNumberOf("depo_limits").
Mixa написал: то оба эти условия выполнятся раньше, чем загрузится лимит.
Ошибаетесь. Если лимит есть на сервере, но еще не загружен в терминал то условие НЕ выполнится и getNumberOf("depo_limits") покажет МЕНЬШЕ чем getServerNumberOf("depo_limits").
Ошибаетесь. Раз данные получены с сервера, значит либо лимит есть и тогда Вы его увидите в depo_limits. Либо лимита нет, просто нет, а не "еще не загружен".
Mixa, Пожелание уже было зарегистрировано (см соседнюю ветку).
Цитата
Mixa написал: У вас выполнится условие getServerNumberOf("depo_limits") == getNumberOf("depo_limits"), когда загрузятся лимиты по любому рынку. А запись в trade_accounts может точно появится раньше, чем загрузятся лимиты по бумаге X.
И что это меняет? Пожелание было зарегистрировано с оговоркой чтобы гипотетическая функция 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 нужный лимит, уже уверенные что данные получены с сервера.
Ваше пожелание зарегистрировано. Мы постараемся рассмотреть его и сообщить Вам результаты анализа. Впоследствии, по результатам анализа, будет приниматься решение о реализации пожелания в будущих версиях ПО.
Mixa написал: С учетом того, что сервер должен отправить "количество строк доступных на сервере" ДО описания параметров таблицы Торговые счета.
Ранее было сказано что у нас нет структуры определяющей строгость загрузки тех или иных данных. Проще говоря, никто не следит за тем какие данные придут точно раньше, а какие точно позже. Очередности просто нет. А значит и поменять ее нельзя. Причина в том что данные едут разными потоками, которые между собой никак специально не синхронизируются. Да есть некое условное представление о том что приедет раньше, а что позже, но это не вбито в коде, а просто устоявшееся поведение, которое может поменяться в любой момент.
Иван написал: Правильно ли понимаю если у меня по какой-то причине будет в течении дня сгенерировано два одинаковых TRANS_ID с одинаковыми номерами - максимум чем мне это грозит при снятии стоп-лоса, это то, что будет снят только 1, а второй останется болтаться?
Для того чтобы снять стоп, параметр TRANS_ID вообще не нужен. В транзакции на снятие стопа есть только номер стоп заявки, это НЕ тоже что TRANS_ID.
TRANS_ID - Нужен исключительно Вам т.е. Вашему роботу. QUIK на него вообще никак не смотрит. Нам не известно какая логика заложена в Вашем роботе, следовательно не можем ответить на вопрос о его поведении.
Иван написал: Мне нужно как-то сгенерировать TRANS_ID - уникальное число со смыслом. А не просто уникальное число.
Не понятно что Вам мешает это сделать Есть понимание какой смысл в TRANS_ID Вам нужен? Если нет, тогда определитесь и далее исходя из этого действуйте.
UNIX TIME - это просто количество секунд начиная с какой-то даты (1 января 1970г). можно получить через тот же os.date Судя по всему, Вам не это нужно. Просто сами определите для себя какое число Вам требуется и сгенерируйте. тех поддержка в этом месте не причем. Вопрос только и только на Вашей стороне. Хотите, считайте тот же UNIX TIME но с 2000 года или "сожмите" дату до нужного размера (например сложив чила) Или другие варианты которые Вам понравятся.
Mixa написал: ДО или ПОСЛЕ загрузки лимитов? Это ключевой момент.
Определите самостоятельно, это не так трудно.
Цитата
Mixa написал: Это будет то же гадание, что и сейчас: загрузились/не загрузились.
Еще раз. Если количество строк в таблице терминала равно количеству строк на сервере, это УЖЕ факт того что данные загрузились. Какие данные? Вы УЖЕ можете проверить т.к. есть факт что они загрузились.
Цитата
Mixa написал: Sergey Gorokhov , вы вообще понимаете разницу между состояниями 1) "загрузка еще не началась", 2) "идет процесс загрузки данных" и 3) "загрузка закончена"?Пока вы не поймете эти базовые вещи, у вас так и будут "вопросы и примеры трудности реализации".
А Вы понимаете, что Вам уже несколько раз было предложено?
Цитата
Mixa написал: Если уведомление получено, а данных нет, значит их действительно нет. Это не то же самое, что сейчас, когда вы не можете определенно сказать "нулевая ли позиция" или "она ещё не получена с сервера" .
И в чем разница: "если количество строк в таблице = количеству на сервере, значит данные загружены, а раз нужных данных в таблице нет, значит их действительно нет.
?? Докажите что Ваше предложение хоть чем-то отличается от нашего? разница только в том что наше в разы проще в реализации.
Цитата
Mixa написал: Как интерпретировать такую информацию: запись {Firm2 = {D, E}} в trade_accounts есть, а самого лимита по бумаге X в таблице лимитов нет?
Выше было сказано, цитата:
Цитата
Sergey Gorokhov написал: Пока лимиты грузятся можно было бы добавить проверку "Флаг загрузки данных".
Ситуация: Запись {Firm2 = {D, E}} в trade_accounts есть, значит права есть. И это точно. флаг, что все данные в таблице загружены получили. Нужного лимита среди данных нет, значит его просто нет (брокер не загрузил)
Цитата
Mixa написал: Конкретизирую вопрос: следует ли из вашего утверждения, что сначала будут ПОЛНОСТЬЮ загружены лимиты по классам D и E для Firm2 и лишь затем в trade_accounts появится запись с {Firm2 = {D, E}}?
Это легко проверить самостоятельно
Цитата
Mixa написал: Добавьте эту информацию в официальную документацию по QLua.
У нас нигде нет никакой структуры определяющей строгость загрузки тех или иных данных.
Иван, Дополним, судя по всему вопрос не технический, а логический. Нам не важно что вы напишите в 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). Вы же всеми силами пытаясь объединить два разных флага в одну функцию по косвенным признакам. А это вызывает вопросы и примеры трудности реализации. Проще говоря, возникает слишком много разных "если". Предложенный пример не будет надёжно работать т.к. наличие прав не всегда равно наличию данных.
Ранее Вы сами предложили
Цитата
Mixa написал: Посчитать количество записей в таблице на сервере и отправить число клиенту. В чем проблема?
Вам предлагалось зарегистрировать такое пожелание. А именно проверку количества строк в таблице с количеством строк доступных на сервере. Если количество совпадает то данные загружены, если нет грузятся. И на наш взгляд такая реализация вкупе с проверкой trade_accounts решает поставленную Вами задачу, без излишних "если".
У пользователя есть права на классы A, B по фирме Firm1 и классы D, E по фирме Firm2. Бумага X торгуется в классах A, C и E Скрипт торгует бумагой X в классе E, соответственно ждет лимит по фирме Firm2: isLimitsLoaded(Firm2, E) Сервер подключен к двум шлюзам: первый шлюз транслирует классы A, B, C по фирме Firm1; второй - классы D, E по фирме Firm2.
После подключения первого шлюза сервер сверяет транслируемые классы с правами пользователя и формирует табличку вида {Firm1 = {A, B}} Пользователю приходят лимиты по бумагам, содержащимся в классах A и B, в т.ч. по бумаге X. Как обычно, в этой части никаких изменений не требуется! И после загрузки всех лимитов (даже если их там было 0) сервер отправляет уведомление клиенту {Firm1 = {A, B}}. Но isLimitsLoaded(Firm2, E) = false, поэтому скрипт ждет.
Далее запускается второй шлюз. И клиенту транслируются лимиты по бумагам D и E. Поскольку лимиты по бумаге X уже были раннее загружены, то повторно не транслируются. Все как обычно, в этой части никаких изменений не требуется! Затем клиенту отправляется уведомление {Firm2 = {D, E}}. Это уведомление формируется на основании прав, не лимитов! После его получения isLimitsLoaded(Firm2, E) = true => Лимиты по бумаге X загружены, можно торговать в классе E .
В данном конкретном примере функция isLimitsLoaded вообще не нужна, и даже "Флаг загрузки данных" не обязателен, хотя его можно было бы добавить при желании:
После подключения первого шлюза сервер сверяет транслируемые классы с правами пользователя и отправляет клиенту trade_accounts в которой уже есть данные вида {Firm1 = {A, B}} Пользователю приходят лимиты по бумагам, содержащимся в классах A и B, в т.ч. по бумаге X. Как обычно, в этой части никаких изменений не требуется! Пока лимиты грузятся можно было бы добавить проверку "Флаг загрузки данных". Но в trade_accounts нет {Firm2 = {D, E}}, поэтому скрипт ждет.
Далее запускается второй шлюз. И клиенту транслируются лимиты по бумагам D и E. Поскольку лимиты по бумаге X уже были раннее загружены, то повторно не транслируются. Все как обычно, в этой части никаких изменений не требуется! Клиент уже может проверить наличие {Firm2 = {D, E}} в trade_accounts Если есть => Лимиты по бумаге X загружены (скрипт может это проверить в таблице лимитов), можно торговать в классе E.
Roman Azarov написал: В текущей реализации, экспорт таблицы текущих торгов возможен только средствами DDE (не обязательно в Excel) и ODBC. Можем зарегистрировать пожелание на возможность экспорта в текстовый файл. Регистрируем?
Зарегистрируйте другое пожелание. Из ТТТ должен открываться таблица, отображающая соответствие названий параметров и их "формальное название". Тогда каждый сам легко и наглядно сможет это соответствие увидеть без всяких DDE и экселов. С обязательной возможностью копирования данных из такой таблицы!!! чтобы не приходилось перепечатывать названия параметров.
Вам в этом случае не придется поддерживать актуальность документации, просто отпадает надобность в документировании.
Ваше пожелание зарегистрировано. Мы постараемся рассмотреть его и сообщить Вам результаты анализа. Впоследствии, по результатам анализа, будет приниматься решение о реализации пожелания в будущих версиях ПО.
Mixa написал: И после всех объяснений, вы бьете себя пяткой в грудь и кричите: "задача не решаема, закрываем!"
Задача не решаема в том контексте который Вы просите. Ранее Вам предлагался признак загрузки всех строк в таблице лимитов - такое пожелание возможно.
Цитата
Mixa написал: Тогда при чем здесь "десятки миллионов лимитов"?
Как уже было сказано, в предложенном варианте, серверу понадобится проверить ранее отправленные лимиты, сверив их с поступившим набором инструментов. Чтобы убедиться что отправка действительно была. Иначе вариант с правами не надежен.
Цитата
Mixa написал: Допустим, получил сервер со шлюза классы "class1,class2,class3" для firmid. Их же он и проверяет в правах (не в лимитах!) пользователей.
Да, сервер проверяет права на классе. Фирма счет (код клиента) и отправляет клиенту те лимиты которые им удовлетворяют. Что это даст не понятно. Например на СПБ американские бумаги, на ФР российские, права одинаковые, лимиты разные. В результате только проверки прав недостаточно.
Цитата
Mixa написал: И это можно использовать для оптимизации: если для пользователя в правах нет ни одного доступного "firmid + class_code" с этого шлюза, то в лимиты можно уже не смотреть.
Cервер так и делает, было же сказано что если прав нет то и лимитов нет.
Андрей написал: Какой правильный формат CLIENT_CODE , если 123456/345 не работает? 345 - это доп данные
В зависимости от настроек на стороне брокера, код клиента и комментарий могут разделяться либо "/" либо "//". Посмотрите как оно выглядит у Вас в таблице заявок
Андрей написал: Он всегда есть в OnOrder, ореде с т.з. елиента. Вы хотите сказать, что вы не можете своими внутренними признаками определить, ручной ордер или нет? Чтобы для ручных возвращать trans_id не так же, как для незаполненных. Ну исторически уже привыкли к 0 для ручных, а для незаполненных тогда просто не возвращать поле (=nil). Из ваших слов про биржу не следует, что вы не можете так формировать свои поля в OnOrder.
Эти "внутренние признаки" есть только на транзакции. Сервер получает транзакцию и запоминает "внутренние признаки" Далее транзакция отправляется на биржу и там регистрируется заявка. Обратно на сервер отправляется две сущности, ответ на транзакцию (текст типа "ваша заявка зарегистрирована...") и тело заявки (то что в таблице ORDERS биржевого интерфейса). Далее серверу нужно найти исходную транзакцию и связать ее с заявкой, происходит это через ответ на транзакцию. В ответе на транзакцию есть номер заявки, в теле заявки тоже есть номер заявки. Таким образом, зная это, сервер может найти исходную транзакцию и взять из нее "внутренние признаки" которые потом установить на теле заявки. Все усложняет то что тело заявки и ответ на транзакцию едут разными потоками, которые никак между собой не синхронизируются. Если ответ на транзакцию приехал раньше тела заявки то проблем нет, сервер заранее определяет "внутренние признаки" и когда заявка приедет, отправит ее клиенту вместе с признаками. Но т.к. потоки не синхронизируются бывают случаи когда тело заявки приезжает ДО ответа на транзакцию. Т.е. сервер получает тело заявки и не может найти исходную транзакцию, тогда тело заявки сразу передается клиенту, а потом, когда поступает ответ на транзакцию, сервер делает еще одну отправку тела заявки, но с уже проставленными "внутренними признаками" Исходя из этого, отвечаем на вопрос, мы не можем своими внутренними признаками определить, ручной ордер или нет до тех пор, пока не получен ответ на транзакцию.
Цитата
Андрей написал: И насчет CLIENT_CODE в транзакции. Я его заполняю своим номером. Как его получить в OnOrder? Там нет такого поля, есть похожее по описанию brokerref, но оно не содержит моих данных, а именно /код клиента.
Да brokerref, там должен быть комментарий. Проверьте еще раз.
Mixa написал: Я вам пишу, что сами лимиты грузить повторно не надо.
Никто не говорил про повторную загрузку. Говорилось про проверку доступности, а не загрузку. Это не одно и то же.
Цитата
Mixa написал: Надо только сверить права на firmid + class_code с теми, что дает шлюз. Если они есть, значит отправляем клиенту уведомление.
По сути это и есть "повторная проверка доступности", разве нет? И как уже было сказано, trade_accounts это как раз и есть проверка прав по firmid + class_code и Вы сами сказали что задачу это не решает.
Цитата
Mixa написал: Давайте я буду общаться с программистом на уровне кода, раз вы не понимаете.
К сожалению, наш внутренний регламент не разрешает связь клиента с разработчиком.
Андрей написал: А свои дополнения можно сделать как пишу выше, чтобы не было неразберихи. Либо =nil (отсутствуют в пришедшем ордере), либо -1, пока вы не вставите истинное значение.
Еще раз, trans_id это наш параметр, его в принципе никогда нет в ордере. Наш сервер его проставляет, а не биржа.
Андрей написал: Приведите пожалуйста полный список полей транзакции, которые входят и в ордера и в биржевой протокол и, значит, заполнены в каждом пришедшем OnOrder.
Mixa написал: А нужно уведомление, что получены все лимиты (для данных firmid + class_code).
К сожалению разговор уже идет по кругу. Никак нельзя определить что лимиты загружены по firmid + class_code. Просто нет и все. Дорабатывать как то сервер ради этого нецелесообразно, значит работать только с тем что есть. А того что есть недостаточно, альтернативный вариант Вас не устраивает. Итого задача не решаема а значит считается закрытой. Ок?
Андрей написал: А вы уверены, что он будет проставлен в этом первом пришедшем OnOrder, в котором даже trans_id не проставлен? Не думаю.. т.к. транзакция еще не обработана.
CLIENT_CODE - это биржевой параметр. Вы отправляете транзакцию на биржу и в OnOrder приезжает тело заявки с биржи, включая CLIENT_CODE.
Цитата
Андрей написал: И в любом случае это bad design, о чем я выше пишу, когда не заполненное поле имеет значение, валидное для заполненного. И исправить это не сложно без потерь производительности, нужно сделать.
Мы не можем что-то добавить в биржевой протокол, только биржа это может. Добавить свои собственные параметры, да можем, и UID и trans_id мы как раз и добавили. Добавить к ним еще один? Зачем он ведь будет работать точно так же. И с ним будут точно такие же проблемы.
Mixa написал: Sergey Gorokhov , вы куда-то ушли от темы.
От чего же, Вы хотели
Цитата
Mixa написал: лимиты "firmid + class_code загружены". Даже если в этой связке было загружено ноль лимитов.
таблица trade_accounts ровно это и покажет. Да она не показывает именно лимиты, но Вы сами же сказали что это и не требуется Ок, смотрите trade_accounts Если там нет нужной "firmid + class_code" значит и лимитов по ним нет. И это точно. Если есть, значит лимиты есть, потому что запись там не появится пока не будет получен лимит по любой бумаге связывающей фирму+счет+код клиента.
Mixa написал: Я не говорю про конкретные инструменты. Сервер отправит уведомление, что лимиты "firmid + class_code загружены". Даже если в этой связке было загружено ноль лимитов.
Тогда смысл в чем? Смотрите колбек OnFirm или таблицу firms, там правда нет класса, есть торговая площадка (по сути рынок). Вот Вам и isLimitsLoaded
Нет, лучше trade_accounts (Торговые счета), там есть связка фирма+счет+список классов