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

Выбрать дату в календареВыбрать дату в календаре

Страницы: 1 2 3 4 5 6 7 8 9 10 11 ... 77 След.
При снятии заявки перемерт account пустой
 
Для заявок OrderNum+ClassCode+TradeDate
Для сделок TradeNum+Operation+ClassCode+TradeDate
Для обезличенных сделок TradeNum+ClassCode+TradeDate+SecCode

на сделках (не обезличенных) нумерация на разных инструментах одного класса не совпадает.
Да это значит что номер одной сделки в обезличенных, и в обычных, может быть разным
При снятии заявки перемерт account пустой
 
Старатель,
Уже был развернутый ответ
При снятии заявки перемерт account пустой
 
Старатель,
Речь о некоторых зарубежных шлюзах, где номер обезличенной сделки может быть один на разных инструментах одного класса.
В свое время, из-за этого SecCode был добавлен в список первичного ключа таблицы AllTrades в модуле экспорта биржевой информации.
При снятии заявки перемерт account пустой
 
Старатель,
К сожалению в ответе произошла ошибка.
Заявки не могут быть с совпадающим номером на одном классе.
И SECCODE на транзакции KILL_ORDER не нужен.
И в Lua тоже. Почему у автора не получилось снять заявку не понятно.
На самом деле номер в разрезе инструмента может совпадать только на обезличенных сделках
Написание автономного бота
 
Mixa,
Вам уже было сказано что согласование с разработчиком возможно исключительно только после регистрации пожелания.
Пожелание зарегистрировано, информация ушла разработчикам, ждите ответ.
Отладка QUIK 9.1
 
Цитата
BlaZed написал:
QUIK создает во всех папках где есть *.lua файлы файл qrypto.log с таким содержанием
Проблема изучается. Постараемся в ближайшее время дать ответ.
Написание автономного бота
 
Цитата
Mixa написал:
Но это же не прямой запрос на сервер. getServerNumberOf вернет последнее значение, полученное с сервера. Или я вас не так понял?
Речь была именно про запрос на сервер. те запрос к серверу, сколько есть на сервере в такой-то таблице.
Написание автономного бота
 
Цитата
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").


Цитата
Mixa написал:
И это заблуждение.
Ошибаетесь.
Раз данные получены с сервера, значит либо лимит есть и тогда Вы его увидите в 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 написал:
С учетом того, что сервер должен отправить "количество строк доступных на сервере" ДО описания параметров таблицы Торговые счета.

Ранее было сказано что у нас нет структуры определяющей строгость загрузки тех или иных данных.
Проще говоря, никто не следит за тем какие данные придут точно раньше, а какие точно позже.
Очередности просто нет. А значит и поменять ее нельзя.
Причина в том что данные едут разными потоками, которые между собой никак специально не синхронизируются.
Да есть некое условное представление о том что приедет раньше, а что позже, но это не вбито в коде, а просто устоявшееся поведение, которое может поменяться в любой момент.
№ номер заявки 1.952337642788e+018 VS 2 952 137 242 587 989 181
 
Цитата
Иван написал:
Правильно ли понимаю если у меня по какой-то причине будет в течении дня сгенерировано два одинаковых TRANS_ID с одинаковыми номерами - максимум чем мне это грозит при снятии стоп-лоса, это то, что будет снят только 1, а второй останется болтаться?
Для того чтобы снять стоп, параметр TRANS_ID вообще не нужен.
В транзакции на снятие стопа есть только номер стоп заявки, это НЕ тоже что TRANS_ID.

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

Код
function main()

  while getServerNumberOf("depo_limits") != getNumberOf("depo_limits") do
    sleep(100)
  end

end
№ номер заявки 1.952337642788e+018 VS 2 952 137 242 587 989 181
 
Цитата
Иван написал:
Мне нужно как-то сгенерировать TRANS_ID - уникальное число со смыслом. А не просто уникальное число.
Не понятно что Вам мешает это сделать
Есть понимание какой смысл в TRANS_ID Вам нужен? Если нет, тогда определитесь и далее исходя из этого действуйте.
№ номер заявки 1.952337642788e+018 VS 2 952 137 242 587 989 181
 
Цитата
Иван написал:
А UNIX TIME как получить?
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.

У нас нигде нет никакой структуры определяющей строгость загрузки тех или иных данных.
№ номер заявки 1.952337642788e+018 VS 2 952 137 242 587 989 181
 
Иван,
Дополним,
судя по всему вопрос не технический, а логический. Нам не важно что вы напишите в TRANS_ID, главное чтобы размер был не больше «2 147 483 647»

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

Если вопрос в том, как в os.date указать выходной формат, то ответ есть в документации на Lua
№ номер заявки 1.952337642788e+018 VS 2 952 137 242 587 989 181
 
Иван,
Вы же сами сказали что от «1» до «2 147 483 647»
В чем сложность сгенерировать число входящее в этот диапозон не понятно.
Если хочется получить его из даты, тот же UNIX TIME вполне в него влезает
Соответствие Кодов клиента и Торговых счетов, Определение соответствия Кодов клиента и Торговых счетов
 
Цитата
Незнайка написал:
Но в форме ввода заявки нет идентификатора фирмы. Как же квик определяет, по какой фирме совершать сделку?

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

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

Цитата
Mixa написал:
Пример:

У пользователя есть права на классы 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.
Получение признака "Субординированный инструмент" в lua
 
Цитата
swerg написал:
Цитата
Roman Azarov написал:
В текущей реализации, экспорт таблицы текущих торгов возможен только средствами DDE (не обязательно в Excel) и ODBC.
Можем зарегистрировать пожелание на возможность экспорта в текстовый файл. Регистрируем?
Зарегистрируйте другое пожелание.
Из ТТТ должен открываться таблица, отображающая соответствие названий параметров и их "формальное название".
Тогда каждый сам легко и наглядно сможет это соответствие увидеть без всяких DDE и экселов.
С обязательной возможностью копирования данных из такой таблицы!!! чтобы не приходилось перепечатывать названия параметров.

Вам в этом случае не придется поддерживать актуальность документации, просто отпадает надобность в документировании.

Ваше пожелание зарегистрировано. Мы постараемся рассмотреть его и сообщить Вам результаты анализа. Впоследствии, по результатам анализа, будет приниматься решение о реализации пожелания в будущих версиях ПО.
Получение признака "Субординированный инструмент" в lua
 
_sk_,
Если права одинаковые, тогда да.
Получение признака "Субординированный инструмент" в lua
 
Цитата
Андрей написал:
Действительно ли могут прийти колбеки заявок других клиентов?
Конечно нет, это исключено. Только брокер может видеть заявки других клиентов.
Написание автономного бота
 
Цитата
Mixa написал:
И после всех объяснений, вы бьете себя пяткой в грудь и кричите: "задача не решаема, закрываем!"
Задача не решаема в том контексте который Вы просите. Ранее Вам предлагался признак загрузки всех строк в таблице лимитов - такое пожелание возможно.
Цитата
Mixa написал:
Тогда при чем здесь "десятки миллионов лимитов"?
Как уже было сказано, в предложенном варианте, серверу понадобится проверить ранее отправленные лимиты, сверив их с поступившим набором инструментов. Чтобы убедиться что отправка действительно была. Иначе вариант с правами не надежен.

Цитата
Mixa написал:
Допустим, получил сервер со шлюза классы "class1,class2,class3" для firmid. Их же он и проверяет в правах (не в лимитах!) пользователей.

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

Цитата
Mixa написал:
И это можно использовать для оптимизации: если для пользователя в правах нет ни одного доступного "firmid + class_code" с этого шлюза, то в лимиты можно уже не смотреть.
Cервер так и делает, было же сказано что если прав нет то и лимитов нет.
Получение признака "Субординированный инструмент" в lua
 
Цитата
Андрей написал:
Какой правильный формат CLIENT_CODE , если 123456/345 не работает? 345 - это доп данные  
В зависимости от настроек на стороне брокера, код клиента и комментарий могут разделяться либо "/" либо "//".
Посмотрите как оно выглядит у Вас в таблице заявок
Получение признака "Субординированный инструмент" в lua
 
Цитата
Андрей написал:
Он всегда есть в OnOrder, ореде с т.з. елиента. Вы хотите сказать, что вы не можете своими внутренними признаками определить, ручной ордер или нет? Чтобы для ручных возвращать trans_id не так же, как для незаполненных. Ну исторически уже привыкли к 0 для ручных, а для незаполненных тогда просто не возвращать поле (=nil). Из ваших слов про биржу не следует, что вы не можете так формировать свои поля в OnOrder.

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

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

Да brokerref, там должен быть комментарий. Проверьте еще раз.
Написание автономного бота
 
Цитата
Mixa написал:
Я вам пишу, что сами лимиты грузить повторно не надо.
Никто не говорил про повторную загрузку.
Говорилось про проверку доступности, а не загрузку. Это не одно и то же.

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

Цитата
Mixa написал:
Давайте я буду общаться с программистом на уровне кода, раз вы не понимаете.
К сожалению, наш внутренний регламент не разрешает связь клиента с разработчиком.
Получение признака "Субординированный инструмент" в lua
 
Цитата
Андрей написал:
А свои дополнения можно сделать как пишу выше, чтобы не было неразберихи. Либо =nil (отсутствуют в пришедшем ордере), либо -1, пока вы не вставите истинное значение.  
Еще раз, trans_id это наш параметр, его в принципе никогда нет в ордере. Наш сервер его проставляет, а не биржа.
Получение признака "Субординированный инструмент" в lua
 
Цитата
Андрей написал:
Приведите пожалуйста полный список полей транзакции, которые входят и в ордера и в биржевой протокол и, значит, заполнены в каждом пришедшем OnOrder.
Это описано в биржевом протоколе, который не является тайной.
описание на сайте биржи:
http://ftp.moex.com/pub/ClientsAPI/ASTS/Bridge_Interfaces/Equities/Equities3­8_Broker_Russian.htm
Написание автономного бота
 
Цитата
Mixa написал:
А нужно уведомление, что получены все лимиты (для данных firmid + class_code).
К сожалению разговор уже идет по кругу.
Никак нельзя определить что лимиты загружены по firmid + class_code.
Просто нет и все.
Дорабатывать как то сервер ради этого нецелесообразно, значит работать только с тем что есть.
А того что есть недостаточно, альтернативный вариант Вас не устраивает.
Итого задача не решаема а значит считается закрытой.
Ок?
Получение признака "Субординированный инструмент" в lua
 
Цитата
Андрей написал:
А вы уверены, что он будет проставлен в этом первом пришедшем 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" значит и лимитов по ним нет. И это точно.
Если есть, значит лимиты есть, потому что запись там не появится пока не будет получен лимит по любой бумаге связывающей фирму+счет+код клиента.
Написание автономного бота
 
Цитата
Sergey Gorokhov написал:
Цитата
Mixa написал:
Я не говорю про конкретные инструменты. Сервер отправит уведомление, что лимиты "firmid + class_code загружены". Даже если в этой связке было загружено ноль лимитов.
Тогда смысл в чем? Смотрите колбек OnFirm или таблицу firms, там правда нет класса, есть торговая площадка (по сути рынок). Вот Вам и isLimitsLoaded

Нет, лучше trade_accounts (Торговые счета), там есть связка фирма+счет+список классов
Написание автономного бота
 
Цитата
Mixa написал:
Я не говорю про конкретные инструменты. Сервер отправит уведомление, что лимиты "firmid + class_code загружены". Даже если в этой связке было загружено ноль лимитов.

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

Сейчас сервер не проверяет те лимиты которые уже были отправлены.
Если делать по Вашему, то серверу придется при появлении каждого инструмента по каждому классу проверять все ранее отправленные лимиты. Такая нагрузка потенциально увеличит время готовности сервера в разы.
Написание автономного бота
 
Цитата
Mixa написал:
isLimitsLoaded(firmid, "TQBR") == true сработает именно после запуска шлюза с классом TQBR.

Не сработает, потому что лимиты уже были отправлены при появлении EQRP_INFO
Написание автономного бота
 
Цитата
Sergey Gorokhov написал:
Еще пример. Сегодня брокер загрузил EQRP_INFO раньше TQBR, SMAL, и Вы в коде напишите isLimitsLoaded(firmid, "EQRP_INFO") и оно сработает. А завтра брокер возьмет и поменяет расписание запуска шлюзов (а почему нет) и Ваш код сломается.

Это можно исправить только если сервер будет помнить для каждого лимита весь список классов. Чтобы можно было в функции указать любой класс. Не так ли.
Еще раз цитата:
Цитата
Sergey Gorokhov написал:
Сделать задуманное означает реализовать/создать привязку лимита к классам. Проще говоря, чтобы по каждому лимиту, где то хранился список классов.Как уже было сказано сейчас такой привязки просто нет, ни в сервере ни в терминале, и никогда не было. Хранить где-то такой список ради одной функции явно выглядит нецелесообразным.
Написание автономного бота
 
Цитата
Mixa написал:
Это тот же самый список классов, который сервер получил со шлюза. Этот список он и должен отправить клиенту.
Еще пример, есть класс EQRP_INFO, и есть классы TQBR, SMAL, во всех трех классах есть одинаковые инструменты.
НО, класс EQRP_INFO транслируется отдельным шлюзом. По Вашей логике, сервер должен отправить Вам только класс EQRP_INFO, а про TQBR, SMAL вообще ничего не сказать.
Так? И что Вам это даст? Вы же торговать явно не в EQRP_INFO будете.
Еще пример. Сегодня брокер загрузил EQRP_INFO раньше TQBR, SMAL, и Вы в коде напишите isLimitsLoaded(firmid, "EQRP_INFO") и оно сработает. А завтра брокер возьмет и поменяет расписание запуска шлюзов (а почему нет) и Ваш код сломается.
Написание автономного бота
 
Цитата
Mixa написал:
Сервер знает, по каким классам он загружает лимиты, т.к.
Не знает он, было сказано же что доступность определяется по первому попавшемуся.  Никаких гарантий что конкретный лимит всегда будет грузиться по конкретному классу.
Получение признака "Субординированный инструмент" в lua
 
Цитата
Андрей написал:
Повторюсь, для осмысленной обработки прихода OnOrder с trans_id=0 нужно отличать его от подобного при ручном вводе заявки.
Можете самостоятельно указать признак в комментарии, см параметр CLIENT_CODE
Цитата

20-ти символьное составное поле, может содержать код клиента и текстовый комментарий (поручение) с тем же разделителем, что и при вводе заявки вручную. Необязательный параметр
Индикаторы для QUIK старше 8.3.2.4
 
Цитата
Let_it_go написал:
Главное отличие второго варианта: в нём рассчитываются все значения мувинга слева направо и потом берётся нужный.
В readme сказано:
Цитата
Все функции требуют предварительного расчета начиная с индекса 1.
Написание автономного бота
 
Цитата
Mixa написал:
сервер должен отправить клиенту список классов, по которым он только что отгрузил лимиты.
Не должен.
Потому что:
Цитата
Sergey Gorokhov написал:
Это не будет работать по простой причине, лимиты не привязаны к классу.
Цитата
Mixa написал:
Решение посложнее - с фильтром по фирмам: isLimitsLoaded(firmid, class_code) покажет true только по той фирме, которая в правах у пользователя

И про это тоже, было сказано:
Цитата
Sergey Gorokhov написал:
Сделать задуманное означает реализовать/создать привязку лимита к классам. Проще говоря, чтобы по каждому лимиту, где то хранился список классов.Как уже было сказано сейчас такой привязки просто нет, ни в сервере ни в терминале, и никогда не было. Хранить где-то такой список ради одной функции явно выглядит нецелесообразным.
Написание автономного бота
 
Цитата
Mixa написал:
Моя идея такова: сервер отправляет true по каждому подключенному шлюзу ПОСЛЕ всех лимитов. Причем, даже если на каком-то шлюзе для пользователя нет доступных лимитов, он должен отправить true в подтверждение, что все ноль доступных лимитов отгружены.Теперь надо понять, к чему эти true привязывать на клиенте.isLimitsLoaded(firm_id, trdaccid or client_code (в зависимости от рынка)) или isLimitsLoaded(firm_id, trdaccid, client_code) даст нам однозначный ответ?

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

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

Цитата
Mixa написал:
Если клиент подключится к серверу, когда все шлюзы уже подключены, сколько раз сервер отправит клиенту количество строк? Один раз или столько же, сколько шлюзов?
Один раз, что вот столько то лимитов для клиента есть прямо сейчас.

Цитата
Mixa написал:
И опять же, сервер не скажет по какому рынку он будет передавать лимиты?
Только в разрезе таблиц, что для фьючерсов столько, для остальных столько.

Цитата
Mixa написал:
Вы будете ждать лимиты по российским бумагам на ФР, а сервер передаст лимиты рынка СПБ, как быть?

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

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

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

Цитата
Mixa написал:
Что должен отправить сервер клиенту и как это что-то клиент должен интерпретировать? С учетом, что шлюзы могут быть запущены в разное время. Хотелось бы увидеть пример. Пока не понятно.
Сервер отправляет клиенту количество строк в таблице с лимитами, а потом отправляет сами лимиты.
Запустили еще шлюз. Сервер отправляет клиенту новое количество строк в таблице с лимитами, а потом отправляет сами новые лимиты.
Написание автономного бота
 
Цитата
Mixa написал:
Как в этом случае будут загружаться лимиты? После запуска какого из шлюзов?

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

Цитата
Mixa написал:
Для решения задачи этого и не требуется. Грубо говоря, нам нужно уведомление, что лимиты по конкретному рынку загружены, но, поскольку в QUIK нет такого понятия "рынок", нужно делать привязку к чему-то другому.
К чему?

Цитата
Mixa написал:
Вы же сами пишите, что сервер может транслировать не все лимиты, которые на него загружены:
Да верно, может отправить не все.
А если так:
узнать когда количество загруженных строк в таблице будет равно количеству на сервере в том состоянии которое доступно пользователю в данный момент.
Написание автономного бота
 
Цитата
Mixa написал:
Кажется понимаю, что вы хотите сказать: в таблицах depo_limits и futures_client_holding нет параметра "Класс". Вы об этом?

Вот именно, что там нет такого параметра.
Причина в том что
Цитата
Sergey Gorokhov написал:
Одна бумага может быть в разных классах и даже на разных биржах.

Цитата
Mixa написал:
Можно сделать привязку к фирме или счету. Если я правильно понимаю, технически это равнозначно:"Загрузка всех лимитов на фондовой секции" == "загрузка лимитов по всем классам фондовой секции" == "загрузка лимитов по всем trdaccid, привязанным к фондовой площадке" == "загрузка лимитов по всем firmid, привязанным к фондовой площадке"

На фондовом и Валютном рынках, сервер выбирает лимиты для отправки по фирме и коду клиента (не торговому счету)
А на срочном, по фирме и торговому счету (НЕ коду клиента)
Код клиента и торговый счет это абсолютно разные вещи. Так на фондовом рынке по одному торговому счету могут торговать сотни клиентов. А на срочном только один.
На всех рынках может быть одна фирма, а могут быть разные. Если делать привязку к фирме, нет абсолютно никаких гарантий что true будет именно по нужной секции.
Банальный пример, срочный и фондовый рынки объединены в одну фирму, isLimitsLoaded(firmid) вернет true, по какому рынку?
Со счетом может быть еще сложнее т.к. на том же СПБ и MOEX счета могут совпадать, а фирмы нет.
Только связка фирма + торговый счет (или код клиента) вернет правильное значение, но опять же без класса, без рынка.

Чем предложенный вариант не устаревает?
Цитата
Sergey Gorokhov написал:
узнать когда количество загруженных строк в таблице будет равно количеству на сервере в том состоянии которое есть в данный момент.
Страницы: 1 2 3 4 5 6 7 8 9 10 11 ... 77 След.
Наверх