QUIK (версия 7.0.1.5)

Страницы: 1 2 3 4 След.
RSS
QUIK (версия 7.0.1.5), function OnTrade(trade), трехкратный вызов на одно событие.
 
Вот такая вот зараза - отработала три раза  :what: !
На 6.17.1.17 такого не наблюдается.
Lbot3D
 
Здравствуйте,
Начиная с последнего обновления сервера, таблица сделок стала обновляемой.
Поэтому событие OnTrade может срабатывать по нескольку раз
Это не ошибка, так и должно быть
 
Вы могли бы развернуто пояснить, при каких условиях/событиях OnTrade придет несколько раз?
 
quio, если вопрос ко мне - то у меня на тестах трехкратное исполнение наблюдается на каждой сделке.
Sergey Gorokhov, это похоже на то, что я совершаю покупку в магазине: получаю товар, а чек мне выдают не один, а целых три.
И они одинаковые.
С вами весело  :sad: .
Lbot3D
 
На сделке, которая является сущностью торговой системы нет некоторых полей, которые есть в QUIK
В частности это UID, TRANS_ID а также набор флагов и ряд других специфичных параметров
Серверу чтобы проставить эти обновленные параметры приходится отправлять сделку несколько раз.
Иначе, отправка сделки задерживалась бы до установки всех параметров, что гораздо хуже чем получить подряд несколько обновлений.
 
О, в сделках появился trans_id? Здорово. Хотя высылать из-за него сделку повторно кажется странным: все биржи поддерживают числовой тег в заявках, который транслируется и для сделок. При этом нет необходимости искать соответствие сделки с trans_id на сервере.

OnTrade несколько раз - это, конечно, прикольно :) Я вот как чувствовал еще много лет назад, и изначально сделал проверку на возрастанаие номера сделки.
 
В прежних версиях QUIK количество купленных-проданных лотов можно было брать из OnTrade(): вести подсчет trade.qty.
В данной версии это уже не будет работать так просто.
Можно, конечно, запоминать приход информации в некую базу_сделок , произвести расчеты, и по приходу следующих порций OnTrade() быстренько так глянуть в эту базу: а не было ли уже этой сделки раньше?
Пока я не вижу критериев, как удалять из этой базы сделку, так как "несколько раз" - расплывчато. Будем копить?
На таких условиях применять OnTrade() становится не очень комфортно.
Lbot3D
 
XXM,

Код
if(TradeId>lastTradeId)
{
  lastTradeId = TradeId;
  // some work...
}

А зачем вам база?
 
Как уже было сказано и еще раз повторю, трансляция нескольких OnTrade есть, будет и от этого избавляться не планируется, по уже озвученным причинам.
Это значит что если данная реализация приводит к неудобству, предложите способ его избежать и мы зарегистрируем пожелание. Варианты типа "сделайте как было" не принимаются.
На вскидку, например можно подумать над добавлением порядкового номера обновления для каждой сущности.
1, 2, 3 и т.д. Тогда, в коде можно будет фильтровать по номеру обновления if num=1 then.

Если возражений нет, предлагаю зарегистрировать такое пожелание.
 
Цитата
quio пишет:
XXM,
Код
   if (TradeId > lastTradeId)
{
  lastTradeId  =  TradeId;
  // some work .. .
}
  

А зачем вам база?
вариант надо доработать. на разных классах могут быть разные диапазоны номеров сделок.
 
Цитата
XXM пишет:
Можно, конечно, запоминать приход информации в некую базу_сделок , произвести расчеты, и по приходу следующих порций OnTrade() быстренько так глянуть в эту базу: а не было ли уже этой сделки раньше?
Собственно, так раньше было с OnOrder, когда он приходил по нескольку раз. В 7-й версии вместо OnOrder по нескольку раз приходят OnTrade. Причём все с абсолютно одинаковыми параметрами.
Цитата
XXM пишет:
Пока я не вижу критериев, как удалять из этой базы сделку, так как "несколько раз" - расплывчато. Будем копить?
А зачем удалять? Я храню таблицы номеров пришедших заявок и сделок.
Цитата
Sergey Gorokhov пишет:
На сделке, которая является сущностью торговой системы нет некоторых полей, которые есть в QUIK
В частности это UID, TRANS_ID а также набор флагов и ряд других специфичных параметров
Серверу чтобы проставить эти обновленные параметры приходится отправлять сделку несколько раз.
Иначе, отправка сделки задерживалась бы до установки всех параметров, что гораздо хуже чем получить подряд несколько обновлений.
Вот действительно непонятно, зачем слать несколько одинаковых колбеков, если уже в первом приходят все параметры. Можете подробнее пояснить?
 
Цитата
Sergey Gorokhov пишет:
Как уже было сказано и еще раз повторю, трансляция нескольких OnTrade есть, будет и от этого избавляться не планируется, по уже озвученным причинам.
Это значит что если данная реализация приводит к неудобству, предложите способ его избежать и мы зарегистрируем пожелание. Варианты типа "сделайте как было" не принимаются.
На вскидку, например можно подумать над добавлением порядкового номера обновления для каждой сущности.
1, 2, 3 и т.д. Тогда, в коде можно будет фильтровать по номеру обновления if num=1 then.

Если возражений нет, предлагаю зарегистрировать такое пожелание.
Это отличный способ.
Возражений нет, зарегистрируйте, пожалуйста!
Lbot3D
 
Цитата
Старатель пишет:
Собственно, так раньше было с OnOrder, когда он приходил по нескольку раз. В 7-й версии вместо OnOrder по нескольку раз приходят OnTrade. Причём все с абсолютно одинаковыми параметрами.
С это фичей мы уже живем дружно не первый год!  :lol:
Цитата
Старатель пишет:
А зачем удалять? Я храню таблицы номеров пришедших заявок и сделок.
Я их обрабатываю один раз.
И чищу сразу.
Цитата
Старатель пишет:
Вот действительно непонятно, зачем слать несколько одинаковых колбеков, если уже в первом приходят все параметры. Можете подробнее пояснить?
Если они, коллбеки, будут как-то (например, по номерам) идентифицированы, то я готов этот вопрос не задавать.
И не спрашивать: а в чем же все-таки смысл второго и третьего отклика OnTrade() :?:
Lbot3D
 
Цитата
XXM пишет:
Цитата
Sergey Gorokhov пишет:
Как уже было сказано и еще раз повторю, трансляция нескольких OnTrade есть, будет и от этого избавляться не планируется, по уже озвученным причинам.
Это значит что если данная реализация приводит к неудобству, предложите способ его избежать и мы зарегистрируем пожелание. Варианты типа "сделайте как было" не принимаются.
На вскидку, например можно подумать над добавлением порядкового номера обновления для каждой сущности.
1, 2, 3 и т.д. Тогда, в коде можно будет фильтровать по номеру обновления if num=1 then.

Если возражений нет, предлагаю зарегистрировать такое пожелание.
Это отличный способ.
Возражений нет, зарегистрируйте, пожалуйста!
Здравствуйте!

Ваше пожелание зарегистрировано. Мы постараемся рассмотреть его и сообщить Вам результаты анализа. Впоследствии, по результатам анализа, будет приниматься решение о реализации пожелания в будущих версиях ПО.
 
Цитата
XXM пишет:
Я их обрабатываю один раз.
И чищу сразу.
По какому принципу чистите? После третьего колбека?
Я не чищу, потому что могут быть различные ситуации повторного прихода колбеков: переключение на другой сервер, сбой на бирже...
 
Я правильно понял?
БИРЖА ===> БРОКЕР ===> КЛИЕНТ - OnTrade() первый раз пролетает "почти пустая"
БРОКЕР ===> КЛИЕНТ - брокер добавляет "...UID, TRANS_ID а также набор флагов и ряд других специфичных параметров"
Сразу добавили, и пусть хоть "Почтой России" доставляют. Куда спешить?
 
Цитата
Вячеслав пишет:
Сразу добавили, и пусть хоть "Почтой России" доставляют. Куда спешить?
Лично Вам некуда спешить, а для других пользователей скорость появления сделки может быть критичной
 
Цитата
Старатель пишет:
По какому принципу чистите? После третьего колбека?
Код
-- 2.2.3 Функция вызывается терминалом QUIK при получении сделки.
function OnTrade(trade)
   table_insert(trades,trade)
end
<...>
--Обработка таблицы сделок
if #trades~=0 then
   while #trades>0 do
      local t=table_remove(trades,1)
      if t~=nil then OnTradeDo(t) end
   end   
end
 
Ордера так же.
Lbot3D
 
Из кода не видно, что вы обрабатываете кобек один раз: сколько раз колбек придёт, столько раз он попадёт в таблицу trades и будет обработан функцией OnTradeDo (или orders для ордеров).
 
Цитата
Sergey Gorokhov пишет:
Это не ошибка, так и должно быть
Серьёзно, может у вас всё же какая-то ошибка, раз вы считаете, что каждый колбек приносит новую информацию, а по факту они одинаковые.
 
Цитата
Старатель пишет:
Цитата
Sergey Gorokhov пишет:
Это не ошибка, так и должно быть
Серьёзно, может у вас всё же какая-то ошибка, раз вы считаете, что каждый колбек приносит новую информацию, а по факту они одинаковые.
Серьезно, обновляются те поля которые пока еще не доступны в LUA
 
Осталось надеяться, что если мы в очередной коллбэк OnTrade увидели установленные поля
  • class_code,
  • sec_code,
  • price,
  • qty (или как он там теперь будет называться),
  • order_num (или как он там теперь будет называться),
  • trade_num,
  • clearing_comission,
  • exchange_comission,
  • tech_center_comission,
  • datetime,
  • settle_date,
то при последующих коллбэках эти поля уже не поменяют свои значения.

Или могут и поменять?  :shock:   :cry:   :evil:
 
Цитата
Серверу чтобы проставить эти обновленные параметры приходится отправлять сделку несколько раз.
Т.е. это зависит от сервера и подобная засада может образоваться и для пользователей Quik 6-й версии?  :shock:
 
Цитата
Sergey Gorokhov пишет:
В частности это UID, TRANS_ID а также набор флагов и ряд других специфичных параметров
Серверу чтобы проставить эти обновленные параметры приходится отправлять сделку несколько раз.
А зачем там эти параметры вообще были нужны? Ведь у сделки при первом ее приходе в терминал уже будет номер заявки а по заявкам эти параметры уже можно было узнать(были обновляемыми). И я так понимаю если по заявке будет несколько сделок каждую из них серверу нужно синхронизировать и в терминал будет прислано несколько обновлений на каждую сделку? Почему не оставили только для заявок, меньше нужно было бы информации повторной пересылать..
 
Цитата
Антон пишет:
а по заявкам эти параметры уже можно было узнать(были обновляемыми
Вы сами ответили на свой вопрос.
Вот именно что "можно узнать" Слово "Узнать" является здесь ключевым. С точки зрения кода, оно означает прошерстить по всем записям и найти нужную из которой подхватить параметры которых на сделке нет.
Цитата
Антон пишет:
будет прислано несколько обновлений на каждую сделку?
Да именно так.
Цитата
Антон пишет:
Почему не оставили только для заявок, меньше нужно было бы информации повторной пересылать..
Потому что пользователи хотели чтобы на сделках был TRANS_ID и другие параметры
 
Хотелось бы увидеть ответы на мои вопросы выше по теме от сотрудников техподдержки.
 
Цитата
_sk_ пишет:
Или могут и поменять?
Чисто технически, да могут поменяться
Чисто практически, такая ситуация маловероятна
Цитата
_sk_ пишет:
Т.е. это зависит от сервера и подобная засада может образоваться и для пользователей Quik 6-й версии?
Да зависит от сервера. Нет на 6й версии такого поведения не будет, так как 6-я версия не поддерживает обновление таблицы сделок.
 
Цитата
Чисто технически, да могут поменяться Чисто практически, такая ситуация маловероятна
Это плохо, если разработчики говорят в терминах вероятностей о поведении программы.

Представим, что пришла информация о сделке, где комиссии указаны нулевые. Это может произойти, если сделки по фьючерсу идут внутри дня. Адекватная торговая программа пишет в какой-нибудь лог информацию о сделке с нулевой комиссией, а потом ВНЕЗАПНО обнаруживается, после прихода ещё одного коллбэка, что комиссии-то ненулевые! Вот засада и головная боль для программиста! Надо либо в лог дописать, что, мол, фигня вышла, вот правильная информация о сделке, либо действовать по принципу: хочешь записать что-то в лог -- подожди некоторое время в надежде, что вдруг всё не так на самом деле.

А хорошо -- это описать, что такие-то и такие-то блоки данных изменяются атомарно и однократно. В документации это будет?
 
Цитата
_sk_ пишет:

А хорошо -- это описать, что такие-то и такие-то блоки данных изменяются атомарно и однократно. В документации это будет?
нет не будет
 
Цитата
_sk_ пишет:
Представим, что пришла информация о сделке, где комиссии указаны нулевые. Это может произойти, если сделки по фьючерсу идут внутри дня. Адекватная торговая программа пишет в какой-нибудь лог информацию о сделке с нулевой комиссией, а потом ВНЕЗАПНО обнаруживается, после прихода ещё одного коллбэка, что комиссии-то ненулевые! Вот засада и головная боль для программиста! Надо либо в лог дописать, что, мол, фигня вышла, вот правильная информация о сделке, либо действовать по принципу: хочешь записать что-то в лог -- подожди некоторое время в надежде, что вдруг всё не так на самом деле.
Вот ещё один пример, когда подстановка значения 0 или "" вместо nil там, где значения в принципе нет, приводит к неопределённому поведению программы.
В программировании это недопустимо.
 
Для моего случая действительно проблема не одного, а нескольких повторных событий OnTrade  решилась довольно легко, путём объявления новой таблицы TradesFinished и небольшой вставки в начало обработки События OnTrade


Код
function OnTradeDo(trade)  --обработка события "OnTrade произошла сделка"     
local m, y
   y=tostring(trade.trade_num).."="..tostring(trade.order_num)
   if TradesFinished[y] then           --таблица с уже обработанными Трейдами за последние N минут
      m="Событие OnTrade для trade_num= "..trade.trade_num..'  order_num= '..trade.order_num.." уже обрабатывалось " 
          m=m..tostring(os.clock() - TradesFinished[y]).." сек назад.  Повторно НЕ ОБРАБАТЫВАЕМ!!!"
      ToLog(m) 
      return
   end
   TradesFinished[y]=os.clock()  -- запомним, чтоб повторно не обрабатывать
....    --Далее идёт сама обработка события (как было до версии 7)

end

Если сделки частые, то с определенной периодичностью таблицу TradesFinished можно очищать от отметок, устаревших более чем на N минут.
 
В документацию QLUA.CHM добавьте, что теперь в таблице, приходящей в коллбэке OnTrade, есть параметр uid. Про trans_id написали, а про uid -- забыли.
 
Цитата
Sergey Gorokhov пишет:
Потому что пользователи хотели чтобы на сделках был TRANS_ID и другие параметры
OnTrade всегда приходит с заполненным полем trans_id?
Если trans_id=0 в сделке, означает ли это, что сделка была совершена вручную? Или нужно подождать второго-третьего колбека, чтобы убедиться в этом?
 
Цитата
Старатель пишет:
Цитата
Sergey Gorokhov пишет:
Потому что пользователи хотели чтобы на сделках был TRANS_ID и другие параметры
OnTrade всегда приходит с заполненным полем trans_id?
Если trans_id=0 в сделке, означает ли это, что сделка была совершена вручную? Или нужно подождать второго-третьего колбека, чтобы убедиться в этом?
Нет, trans_id может быть сначала 0, если заявка быстро исполнилась на бирже. Потом, в последующих коллбэках, будет выставлено правильное значение trans_id. Если сделка была ручная, то trans_id останется нулём. Придёт ли в этом случае второй-третий коллбэк -- непонятно.

Вообще, раньше OnTrade был самым надёжным коллбэком (OnTransReply может не придти, OnOrder приходит несколько раз и, обычно, с запозданием), а теперь и OnTrade испортился. Ситуация стала похожа на вопрос о том, закрылась очередная свеча или нет.

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

Вообще, было бы круто реализовать в lua абстракцию, где можно оперировать заявками-объектами, ставить их, снимать (даже если от биржи ещё не пришёл order_num). При этом вся кухня с trans_id и т.п. была бы скрыта от пользователя в недрах терминала. Но, к сожалению, разработчики просто поставляют пользователям данные, как получится, пусть пользователи сами разбираются.
 
Цитата
Sergey Gorokhov пишет:
Цитата
_sk_ пишет:
А хорошо -- это описать, что такие-то и такие-то блоки данных изменяются атомарно и однократно. В документации это будет?
нет не будет
Раз уж разработчики сделали такой неопределённый функционал, хотелось бы, чтобы вы поделились известной для вас на текущий момент информацией, как это работает:
Какие параметры являются обновляемыми?
Сколько должно быть колбеков на одну сделку? Есть ли какое-то определённое число? Известно ли оно вам?

Ну и примерный алгоритм действий в следующей ситуации:
Задача состоит в том, чтобы при получении сделки, совершённой вручную, выполнить определённые действия. Из предыдущего комментария следует, что trans_id является обновляемым параметром, и, если там 0, то это значит, что этот параметр может быть ещё не заполнен. А может быть заполнен... В общем, надо угадать...
 
Цитата
Старатель пишет:
Какие параметры являются обновляемыми?
Все параметры которых нет на бирже, плюс те параметры которые на бирже можно менять, являются обновляемыми.
Речь не только про TRANS_ID (это только частный случай) , есть еще комиссия брокера, флаги, UID и др.

Цитата
Старатель пишет:
Сколько должно быть колбеков на одну сделку? Есть ли какое-то определённое число? Известно ли оно вам?
от 1 до бесконечности.

Цитата
Старатель пишет:
Задача состоит в том, чтобы при получении сделки, совершённой вручную, выполнить определённые действия. Из предыдущего комментария следует, что trans_id является обновляемым параметром, и, если там 0, то это значит, что этот параметр может быть ещё не заполнен. А может быть заполнен... В общем, надо угадать...
Можно использовать комментарий.
 
 
Цитата
Sergey Gorokhov пишет:
Все параметры которых нет на бирже, плюс те параметры которые на бирже можно менять, являются обновляемыми.
Речь не только про TRANS_ID (это только частный случай) , есть еще комиссия брокера, флаги, UID и др.
Насколько я понимаю, список параметров сделки является стандартным и конечным, независимо от биржи и торговой площадки.
Поэтому обозначить, какие именно параметры являются не обновляемыми для вас не составит труда.
Обновляемые параметры мы уж определим сами методом исключения.
Цитата
Sergey Gorokhov пишет:
Цитата
Старатель пишет:
Задача состоит в том, чтобы при получении сделки, совершённой вручную, выполнить определённые действия. Из предыдущего комментария следует, что trans_id является обновляемым параметром, и, если там 0, то это значит, что этот параметр может быть ещё не заполнен. А может быть заполнен... В общем, надо угадать...
Можно использовать комментарий.
Вы предлагаете при подаче ручного поручения пользователю забивать ещё комментарий?
 
Цитата
Старатель пишет:
Поэтому обозначить, какие именно параметры являются не обновляемыми для вас не составит труда.
Обновляемые параметры мы уж определим сами методом исключения.
Вы можете самостоятельно определить список, просто взглянув на описание биржевого интерфейса.
Цитата
Старатель пишет:
Вы предлагаете при подаче ручного поручения пользователю забивать ещё комментарий?
Я предлагаю роботу писать некий символ в комментарии который будет однозначно определять транзакцию как поданную роботом.
Все остальное, что не содержит этот спец символ, считать поданным вручную.
 
Цитата
Sergey Gorokhov пишет:
Цитата
Старатель пишет:
Сколько должно быть колбеков на одну сделку? Есть ли какое-то определённое число? Известно ли оно вам?
от 1 до бесконечности.
Вот здесь поподробнее, пожалуйста: обновляемые параметры могут обновляться до бесконечности?

Цитата
Sergey Gorokhov пишет:
Вы можете самостоятельно определить список, просто взглянув на описание биржевого интерфейса.
Нужно угадать как называется тот или иной биржевой параметр в вашей интерпретации?

Цитата
Sergey Gorokhov пишет:
Я предлагаю роботу писать некий символ в комментарии который будет однозначно определять транзакцию как поданную роботом.
У пользователя может быть куча других роботов, алго-приводов и пр., где параметры транзакций уже давно жёстко заданы производителем.
 
Цитата
Старатель пишет:
Sergey Gorokhov пишет:
Цитата
Старатель пишет:
Сколько должно быть колбеков на одну сделку? Есть ли какое-то определённое число? Известно ли оно вам?
от 1 до бесконечности.
Вот здесь поподробнее, пожалуйста: обновляемые параметры могут обновляться до бесконечности?
Будет обновляться столько раз сколько потребуется.
Сколько потребуется нам не известно
Цитата
Старатель пишет:
Цитата
Sergey Gorokhov пишет:
Вы можете самостоятельно определить список, просто взглянув на описание биржевого интерфейса.
Нужно угадать как называется тот или иной биржевой параметр в вашей интерпретации?
Да именно так, как уже было сказано мы публиковать список не будем.
Банально потому что не видим в этом смысла.
Цитата
Старатель пишет:
Цитата
Sergey Gorokhov пишет:
Я предлагаю роботу писать некий символ в комментарии который будет однозначно определять транзакцию как поданную роботом.
У пользователя может быть куча других роботов, алго-приводов и пр., где параметры транзакций уже давно жёстко заданы производителем
Значит нужно изменить логику Вашего робота.
Вы очень умело оспариваете любую попытку помочь, однако сами ни разу не озвучили какого-либо предложения.
 
Цитата
Sergey Gorokhov пишет:
Вы очень умело оспариваете любую попытку помочь, однако сами ни разу не озвучили какого-либо предложения.
Отчего же? Я давно говорил и ещё раз подтверждаю:
Цитата
Старатель пишет:
подстановка значения 0 или "" вместо nil там, где значения в принципе нет, приводит к неопределённому поведению программы.
В программировании это недопустимо.
А суть такова, что проставлять нужно только те параметры, которые заведомо имеют какое-то значение. Параметры, не имеющие значений должны быть nil.
Тогда робот, получивший колбек, в котором, не проставлены интересующие его параметры, будет понимать, что нужно ждать следующего колбека.

В данной ситуации это выглядело бы так:
При получении сделки с бижи, если сервр не успел проставить номер транзакции, то он так и отправляет сделку с trans_id=nil (а не 0).
После, когда сервер будет отправлять следующий колбек, он уже проставит номер транзакции.

Но, учитывая ваш комментарий
Цитата
Sergey Gorokhov пишет:
Цитата
Старатель пишет:
Вот здесь поподробнее, пожалуйста: обновляемые параметры могут обновляться до бесконечности?
Будет обновляться столько раз сколько потребуется.
Сколько потребуется нам не известно
возникает вопрос: если мы получили сделку с проставленным trans_id, можно ли рассчитывать, что он в будущем не изменится?
 
Цитата
Старатель пишет:
подстановка значения 0 или "" вместо nil там, где значения в принципе нет, приводит к неопределённому поведению программы.
В программировании это недопустимо.
А суть такова, что проставлять нужно только те параметры, которые заведомо имеют какое-то значение. Параметры, не имеющие значений должны быть nil .
Тогда робот, получивший колбек, в котором, не проставлены интересующие его параметры, будет понимать, что нужно ждать следующего колбека.

В данной ситуации это выглядело бы так:
При получении сделки с бижи, если сервр не успел проставить номер транзакции, то он так и отправляет сделку с trans_id=nil (а не 0 ).
После, когда сервер будет отправлять следующий колбек, он уже проставит номер транзакции.
Пожелание зарегистрировали.
Однако, конкретно с trans_id это не решит проблему.
Так как trans_id="0" мы не можем указать в транзакции, а значит получив trans_id=nil или как сейчас trans_id=0 реакция будет одной и той же.

Цитата
Старатель пишет:
возникает вопрос: если мы получили сделку с проставленным trans_id, можно ли рассчитывать, что он в будущем не изменится?
Не совсем так, в штатной ситуации да действительно, если trans_id есть то поменяться он уже не может.
Но в случае сбоя на стороне сервера, есть вероятность что сделка может приехать без UID и без trans_id
 
Цитата
Sergey Gorokhov пишет:
Пожелание зарегистрировали.
Однако, конкретно с trans_id это не решит проблему.
Так как trans_id="0" мы не можем указать в транзакции, а значит получив trans_id=nil или как сейчас trans_id=0 реакция будет одной и той же.
На сервер отправляются транзакции либо без trans_id (поданные вручную; из стакана, используя панель ввода заявок) либо с проставленным trans_id, отличным от нуля (поправьте, если ошибаюсь), поданные с помощью QLua, QPILE, API, tri-файла. Таким образом, trans_id=0 никем не зарезервирована. Следовательно, сервер, получив транзакцию без trans_id, сразу помечает её нулём, чтобы в будущем это использовать.
При отправке колбеков с сервера на терминал trans_id=0 можно использовать для обозначения, что данный параметр проставлен. Если параметр не проставлен, то он = nil.
Таким образом, получив колбек с trans_id (или любым другим параметром) = nil мы понимаем, что данный параметр не был проставлен в текущем колбеке и нужно ждать следующего колбека. Если же trans_id=0, то это будет автоматически означать, что транзакция была подана без параметра trans_id, т.е. вручную.

Цитата
Sergey Gorokhov пишет:
Но в случае сбоя на стороне сервера, есть вероятность что сделка может приехать без UID и без trans_id
Я имею ввиду, что если мы получили trans_id, uid (или любой другой параметр), отличный от 0 или "", то можно ли рассчитывать, что в штатной ситуации этот параметр уже не изменится?
Цитата
Sergey Gorokhov пишет:
Не совсем так, в штатной ситуации да действительно, если trans_id есть то поменяться он уже не может.
Это справедливо для всех параметров?
 
Цитата
Старатель пишет:
Если параметр не проставлен, то он = nil .
Таким образом, получив колбек с trans_id (или любым другим параметром) = nil мы понимаем, что данный параметр не был проставлен в текущем колбеке и нужно ждать следующего колбека.
Вы не совсем понимаете как оно работает.
Когда сделка приезжает на сервер, то сервер понятия не имеет есть на ней trans_id или нет., и не знает должен он вообще на ней быть или нет. Чтобы сервер узнал что на сделке есть trans_id и проставил trans_id=0, он должен найти транзакцию.
Ровно это он сейчас делает чтобы проставить trans_id
Вы же предлагаете чтобы сервер делал одну и ту же работу два раза.
первый раз он будет искать транзакцию по сделке чтобы проставить trans_id=0
а второй раз чтобы проставить правильный trans_id
масло масленое получается.

Цитата
Старатель пишет:
Это справедливо для всех параметров?
нет не для всех, а только для тех которые берутся из транзакции, конкретно UID и trans_id
 
Цитата
Sergey Gorokhov пишет:
Вы же предлагаете чтобы сервер делал одну и ту же работу два раза.
первый раз он будет искать транзакцию по сделке чтобы проставить trans_id=0
а второй раз чтобы проставить правильный trans_id
Вы что-то путаете: это вы сейчас делаете двойную работу.
Судя по сообщению #34 (вы же не опровергли его), в общем случае, сервер сначала проставляет trans_id=0, а затем проставляет правильный trans_id.

Я же предлагаю при получении транзакции от клиента сохранить эту транзакцию с trans_id, если его не было, со значением "по-умолчанию" = 0.
Далее, когда сделка приезжает на сервер, в общем случае отправлять её клиенту, раз уж транзакцию ещё не нашли, без проставленного параметра.

А когда транзакция найдётся, то проставить найденное значение параметра. И там будет либо номер транзакции либо честный ноль.

Я правильно понимаю, что весь это "сыр-бор", чтобы отправить сделку клиенту сразу по получению с биржи, не "шурша" по БД SQL в поисках недостающих параметров (в частности trans_id и uid), а эти параметры отправятся следом, когда выполнится команда SELECT?
 
Цитата
Старатель пишет:
Вы что-то путаете: это вы сейчас делаете двойную работу.
Судя по сообщению #34 (вы же не опровергли его), в общем случае, сервер сначала проставляет trans_id=0, а затем проставляет правильный trans_id.
То есть Вы хотите чтобы "0" стал номером транзакции по умолчанию для заявок/сделок?
И чтобы сервер его проставлял сам после получения информации.
Ну тогда колбеки будут сыпаться по несколько раз еще чаще чем сейчас, разве не с этим мы тут боремся?

Цитата
Старатель пишет:
Я правильно понимаю, что весь это "сыр-бор", чтобы отправить сделку клиенту сразу по получению с биржи, не "шурша" по БД SQL в поисках недостающих параметров (в частности trans_id и uid), а эти параметры отправятся следом, когда выполнится команда SELECT?
Об этом как раз и говорилось с самого начала.
 
Цитата
Sergey Gorokhov пишет:
То есть Вы хотите чтобы "0" стал номером транзакции по умолчанию для заявок/сделок?
И чтобы сервер его проставлял сам после получения информации.
Ну тогда колбеки будут сыпаться по несколько раз еще чаще чем сейчас, разве не с этим мы тут боремся?
А разве сейчас у вас 0 - не есть значение "по-умолчанию" для trans_id?
Только в текущей реализации при получении значения 0 мы не можем с уверенность сказать, действительно ли там 0 или просто сервер ещё не нашёл транзакцию.

Я предлагаю не проставлять значения, если его ещё нет. А для trans_id использовать "честный 0", чтобы отличать заявки, поданные вручную от автоматизированных.

Цитата
Sergey Gorokhov пишет:
Ну тогда колбеки будут сыпаться по несколько раз еще чаще чем сейчас
Поясните.

Цитата
Sergey Gorokhov пишет:
разве не с этим мы тут боремся?
Не знаю, как вы, но я борюсь за предсказуемое поведение программы: не должно быть двусмысленного толкования значений параметров.
 
Цитата
Старатель пишет:
А разве сейчас у вас 0 - не есть значение "по-умолчанию" для trans_id?
Только в текущей реализации при получении значения 0 мы не можем с уверенность сказать, действительно ли там 0 или просто сервер ещё не нашёл транзакцию.
0 это не значение по умолчанию, а отсутствие значения, ибо trans_id нельзя задать равным 0.
А Вы как раз хотите его сделать значением. То есть чтобы сервер его проставлял как сейчас не нулевой trans_id
Цитата
Старатель пишет:
Sergey Gorokhov пишет:
Ну тогда колбеки будут сыпаться по несколько раз еще чаще чем сейчас
Поясните.
Так как сервер будет проставлять сам trans_id=0 это приведет к тому же что сейчас происходит с trans_id не равным 0.
Цитата
Старатель пишет:
Цитата
Sergey Gorokhov пишет:
разве не с этим мы тут боремся?
Не знаю, как вы, но я борюсь за предсказуемое поведение программы: не должно быть двусмысленного толкования значений параметров.
я не вижу в trans_id=0 двусмысленного толкования.
 
Цитата
Sergey Gorokhov пишет:
0 это не значение по умолчанию, а отсутствие значения, ибо trans_id нельзя задать равным 0.
Отсутствие значения параметра в принципе или отсутствие оного у текущего колбека? Не путайте эти два понятия.

Цитата
Sergey Gorokhov пишет:
я не вижу в trans_id=0 двусмысленного толкования.
Тогда ответьте на вопрос, который вы "не заметили":
Цитата
Старатель пишет:
OnTrade всегда приходит с заполненным полем trans_id?
Если trans_id=0 в сделке, означает ли это, что сделка была совершена вручную? Или нужно подождать второго-третьего колбека, чтобы убедиться в этом?
Цитата
Sergey Gorokhov пишет:
Так как сервер будет проставлять сам trans_id=0 это приведет к тому же что сейчас происходит с trans_id не равным 0.
А что сейчас происходит с trans_id, не равным 0? Почему колбеки будут сыпаться чаще?
 
Вы задаете одни и те же вопросы по кругу, предлагаю самостоятельно прочитать тему с начала.
На вопросы больше не вижу смысла отвечать
Страницы: 1 2 3 4 След.
Читают тему (гостей: 2)
Наверх