Createsource и смена сессии

Страницы: 1 2 След.
RSS
Createsource и смена сессии
 
После получения сигнала смены сессии я отписываюсь от всех инструментов и подписываюсь заново. Как понимаю, это необходимо при возможном изменении истории инструмента при смене сессии.

Подписка на инструмент сразу после смены сессии ошибок не возвращает, но и "мёд не носит" - свечи не приходят, колбек не дергается.

Как нужно делать правильно?

Спасибо.
www.bot4sale.ru

Пасхалочка для Алексея Иванникова: https://forum.quik.ru/messages/forum10/message63088/topic7052/#message63088
 
Добрый день.

Нужно разбираться. По идее если класс есть, инструмент есть, то и подписка должна произойти.
Нужен код для понимания, где и в какой момент Вы вызываете CreateDataSource(), с какими параметрами.
 
Сам код привести довольно трудно. он весьма объёмный

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

Подписка на событие  oncleanup выглядит элементарно:

oncleanup.subscribe(function()
unsubscribe()
subscribe()
 end)

сначала отписываемся ото всего, потом подписываемся. Реальный вызов функции subscribe происходит не в колбеке, а ставится в очередь в процессе main

все те же действия происходят и по onconnected ровно тем же механизмом

onconnected.subscribe(function()
unsubscribe()
subscribe()
 end)

И с onconnected проблемы не возникают.

проверки возвращаемого значения createdatasource есть.
www.bot4sale.ru

Пасхалочка для Алексея Иванникова: https://forum.quik.ru/messages/forum10/message63088/topic7052/#message63088
 
Интересно, а подписку на получение параметров ТТТ тоже нужно делать заново при смене сессии?
 
Добрый день.

Вы пишите, что  при срабатывании OnConnected() все нормально работает, то это говорит о том, что в момент срабатывания OnCleanUp() терминал еще не получил нужный класс с сервера Quik.

С технической точки зрения так оно и работает, сначала терминал получает с сервера сигнал смены сессии, срабатывает OnCleanUp(), чистятся старые данные, но терминал не чистит статические справочники, т.е. справочник классов и инструментов сохраняются (именно по этой причине подписка не возвращает ошибки, т.к. указанные класс и инструмент в терминале существуют), но подписка не выполняется т.к. фактически на терминале еще нет новых идентификаторов класса и инструмента из новой сессии. А вот когда уже срабатывает OnConnected(), это говорит о том, что класс с сервера получен, и уже можно подписываться на свечки.

Правильно подписываться на свечки после OnConnected().
 
Спасибо.

то есть в моем варианте все манипуляции на сигнал oncleanup просто не нужны и oncleanup всегда предваряет onconnected?
www.bot4sale.ru

Пасхалочка для Алексея Иванникова: https://forum.quik.ru/messages/forum10/message63088/topic7052/#message63088
 
Странно, что терминал выдает успех на cresteddatasource, если реальная подписка не осуществлена.

и вдвойне странно, что если на oncleanup подписаться не смогли, то почему то и на onconnected тоже не удается..
www.bot4sale.ru

Пасхалочка для Алексея Иванникова: https://forum.quik.ru/messages/forum10/message63088/topic7052/#message63088
 
Цитата
s_mike@rambler.ru написал:
Странно, что терминал выдает успех на cresteddatasource, если реальная подписка не осуществлена.
Это не "странно", это баг. Что за data_source возвращается в таком случае, вообще не понятно:
Код
CreateDataSource("SPBFUT", "", INTERVAL_M1)
Надо делать так, как надо. А как не надо - делать не надо.
 
Проблема изучается. Постараемся в ближайшее время дать ответ.
 
Добрый день,
     
      При вызове функции CreateDataSource не проверяется валидность       введенного инструмента и интервала. Данная ошибка будет исправлена       в одной из очередных версий программы.
      Приносим извинения за причиненные неудобства!
QUIK clients support
 
Т.е. вот это обращение таки будет принято как ошибка:
https://forum.quik.ru/messages/forum10/message40946/topic4190/#message40946
 
По размышлению возник вопрос, а зачем вообще при дисконнекте закрывать потоки, созданные createdatasource()? Они автоматом разве не закроются? Что вообще произойдет с открытым потоком, если соединение разорвется, а затем восстановится?
 
Цитата
Сергей написал:
По размышлению возник вопрос, а зачем вообще при дисконнекте закрывать потоки, созданные createdatasource()? Они автоматом разве не закроются? Что вообще произойдет с открытым потоком, если соединение разорвется, а затем восстановится?

Терминал QUIK автоматом закроет поток если он не используется.
При реконнекте подписка не теряется.
 
Цитата
Sergey Gorokhov написал:
Цитата
Сергей написал:
По размышлению возник вопрос, а зачем вообще при дисконнекте закрывать потоки, созданные createdatasource()? Они автоматом разве не закроются? Что вообще произойдет с открытым потоком, если соединение разорвется, а затем восстановится?

Терминал QUIK автоматом закроет поток если он не используется.
При реконнекте подписка не теряется.
а разве нумерация свечей останется неизменной? Старые свечи разве не могут обрезаться?
www.bot4sale.ru

Пасхалочка для Алексея Иванникова: https://forum.quik.ru/messages/forum10/message63088/topic7052/#message63088
 
s_mike@rambler.ru,
Не понятно причем тут это, речь же была про подписку а не про свечи.
Свечи да могут быть обрезаны с лева, нумерация при этом сдвинется.
 
Цитата
Sergey Gorokhov написал:
s_mike@rambler.ru,
Не понятно причем тут это, речь же была про подписку а не про свечи.
Свечи да могут быть обрезаны с лева, нумерация при этом сдвинется.
работа с котировками инструментов  у меня - единый объект, который и подписки делает и с историей работает. В том числе занимается кэшированием. Поэтому при переподключении необходимо пересоздать весь объект, который при создании переподпишется и дальше снова начнет создавать кеши котировок.

сейчас, когда терминал не может внятно сказать, удачно ли он подписался на котировку, нет возможности отследить, почему нет котировок. Или нет свечей в принципе, или они ещё не получены, или подписка не прошла.
www.bot4sale.ru

Пасхалочка для Алексея Иванникова: https://forum.quik.ru/messages/forum10/message63088/topic7052/#message63088
 
Цитата
s_mike@rambler.ru написал:
сейчас, когда терминал не может внятно сказать, удачно ли он подписался на котировку,
Да и это ошибка, которую мы уже изучили и уже признали.

Цитата
s_mike@rambler.ru написал:
нет возможности отследить, почему нет котировок. Или нет свечей в принципе,
да такой возможности нет, и сам сервер этого не знает.
От куда серверу знать будут ли торги по инструменту или трейдеры вообще ничего сегодня не купят?
никто этого знать не может
и сервер тоже не может.

Цитата
s_mike@rambler.ru написал:
или они ещё не получены, или подписка не прошла.
Это та же тема что и первый пункт про неправильный статус createdatasource?
Если так то ответ уже был.
 
Цитата
Sergey Gorokhov написал:
Цитата
s_mike@rambler.ru написал:
сейчас, когда терминал не может внятно сказать, удачно ли он подписался на котировку,
Да и это ошибка, которую мы уже изучили и уже признали.

Цитата
s_mike@rambler.ru написал:
нет возможности отследить, почему нет котировок. Или нет свечей в принципе,
да такой возможности нет, и сам сервер этого не знает.
От куда серверу знать будут ли торги по инструменту или трейдеры вообще ничего сегодня не купят?
никто этого знать не может
и сервер тоже не может.

Цитата
s_mike@rambler.ru написал:
или они ещё не получены, или подписка не прошла.
Это та же тема что и первый пункт про неправильный статус createdatasource?
Если так то ответ уже был.
ответ к делу не пришьешь.

я вам писал о неправильном ответе createdatasource уже лет 5 назад и вы регистрировали, рассматривали, обсуждали, митинговали, постановили и дали торжественные обещания. Результат известен.
www.bot4sale.ru

Пасхалочка для Алексея Иванникова: https://forum.quik.ru/messages/forum10/message63088/topic7052/#message63088
 
s_mike@rambler.ru,
Михаил,
Да и сейчас мы надеемся что большая часть этих кейсов или даже все будут закрыты.
Не могу ответить уверенно т.к. исправление еще не вышло.
 
Цитата
Sergey Gorokhov написал:
Цитата
s_mike@rambler.ru написал:
нет возможности отследить, почему нет котировок. Или нет свечей в принципе,
да такой возможности нет, и сам сервер этого не знает.
От куда серверу знать будут ли торги по инструменту или трейдеры вообще ничего сегодня не купят?
Машину времени изобретаете? Об этом никто и не спрашивал.
Пусть сервер скажет: у меня свечей нет сейчас, узбагойся чувак. Но он же ж молчит, аки партизан. А ты крутись, программер, как хошь.
Надо делать так, как надо. А как не надо - делать не надо.
 
Старатель,
По идее он должен вернуть пустые значения, разве нет?
 
Цитата
Sergey Gorokhov написал:
По идее он должен вернуть пустые значения, разве нет?
А как понять, что сервер уже вернул эти пустые значения? Они ведь у вас по дефолту и так возвращаются. Пусть, скажет, что у него нет свечей, чтоб не ждать понапрасну.

Типа такой функции что ли:

DS:Чё_Есть_На_Сервере_Брокера()
true - свечи есть
false - нет свечей
nil - информации о наличии свечей пока нет, но она обязательно будет, приходите позже
Надо делать так, как надо. А как не надо - делать не надо.
 
Цитата
Старатель написал:
А как понять, что сервер уже вернул эти пустые значения? Они ведь у вас по дефолту и так возвращаются. Пусть, скажет, что у него нет свечей, чтоб не ждать понапрасну.
Было же сказано что это ошибка
 
Вы сейчас о какой именно ошибке?
Последние два поста я вам пишу о ситуации, когда задан валидный инструмент, но графика нет по нему.
Надо делать так, как надо. А как не надо - делать не надо.
 
Цитата
Старатель написал:
Последние два поста я вам пишу о ситуации, когда задан валидный инструмент, но графика нет по нему.
В такой ситуации должен возвращать пустые значения.

т.е. сейчас пустые значения возвращаются и по делу и не по делу
когда исправим это, ожидается что пустые значения будут только по делу, т.е. как раз когда инструмент валиден, а данных нет.
это и будет Ваше false - нет свечей
если значение не пустые, начит true - свечи есть
про nil не понятно, при каких обстоятельствах он по Вашему должен проявляться.
и не понятно, как сервер должен понять что информация "обязательно" будет, ведь Вы сами сказали что мы не про машину времени.
 
Тогда уже добавьте метод проверки: все данные загружены. Или сделать подписку на колбек: при пролучении всех данных.
В конкретный момент времени данные либо еще загружаются из-за большого объема или слабый канал связи, либо уже все получено.
Это бы позволило избавиться от вских безумных задержек, проверок по времени и т.д.

По идее, у всех методов заказа данных с сервера, должен быть колбек по получению всего объема этих данных. Как никак клиент-серверная архитектура.
 
Nikolay,
дайте определение фразе "все данные загружены" в условиях непрерывного поступления данных, тогда подумаем над реализацией.
А если серьезно то этому вопросу уже десятки лет, никто так и не смог нормально ответить, то такое "все данные загружены"
Вот вы заказали свечки, на момент их заказа было 100шт, а когда получили последнюю 100 свечку, уже появилась 101 шт, это считается "все данные загружены"?
 
Sergey Gorokhov,
Рассмотрите на примере http-сервера.
Когда запрашиваемой страницы нет, но есть заглушка, вы видите страницу 404.
Если заглушки нет, то вы будете целый день сидеть перед пустым монитором или пока не надоест. Придумали в прошлом веке, а вы говорите "десятки лет"...
Надо делать так, как надо. А как не надо - делать не надо.
 
Т.е. невозможно дать сигнал когда выбрана вся выборка? Вот у меня на сервере есть массив. Я отдаю его прциями через канал связи. В последней порции идет флаг, что это последний пакет.
Терминал видит оный и после загрузки этого пакета дает колбек. У вас же есть колбек для получения новых данных по барам - это он и есть, т.к. он вызывается для каждой последней сделки, читай порции данных. Только в случае отсутвия сделок у нас колбека нет и приходится гадать получены ли все пакеты.

В вашем примере - это не будет проблема, т.к. появление нового бара всего лишь дать мне результат Size() = 101, а не 100. Но я уверен, что это уже послений бар. Его номер не столь важен, пока не все получено.
 
Старатель,
Вы сейчас про "все данные загружены" или про nil?
 
Nikolay,
давайте еще раз.
Мы говорим про условия постоянного появления свежих данных
Постоянного, понимаете? Как телевизор который непрерывно показывает разные программы.
Там нет такого понятия как "последний" пакет данных.
 
Цитата
Старатель написал:
на примере http-сервера
Это ложная аналогия, в http размер файла известен заранее и посылается в заголовке ответа, поэтому и можно сказать, когда файл передан полностью. В первых-то вариантах протокола размер не передавался, сигналом завершения передачи был разрыв соединения сервером и случаи "приехало полфайла и браузер ничего не заметил" были сплошь и рядом. В асинхронном потоковом протоколе в принципе нельзя отличить ситуацию "нет данных" от ситуации "порвался провод", посмотрите хоть на UART и все его производные.
 
Цитата
Sergey Gorokhov написал:
про nil не понятно, при каких обстоятельствах он по Вашему должен проявляться.
nil - это, когда вы запрашиваете DS:Чё_Есть_На_Сервере_Брокера() до того, как клиент получил информацию с сервера. Биты, они, ведь, не мгновенно передаются, понимаете?

Цитата
Sergey Gorokhov написал:
и не понятно, как сервер должен понять что информация "обязательно" будет
Из понимания, как оно должно работать. Сервер обязан уведомить клиента как о наличии свечей (тогда он сразу передаёт сами свечи), так и об отсутствии свечей (флаг false).
Вы же сами пишите:
Цитата
Sergey Gorokhov написал:
По идее он должен вернуть пустые значения
А вот мы не знаем, возвращает ли сервер что-то, если графика нет. Клиент сразу создаёт пустой объект. Как понять, что сервер уже чё-то вернул?
В вашем случае ожидание
Код
while DS:Size() == 0 do sleep end
может привести к бесконечному циклу.

Сравните:
Код
while DS:Чё_Есть_На_Сервере_Брокера() == nil do sleep end
if DS:Чё_Есть_На_Сервере_Брокера() == true then
  -- свечи есть, работаем дальше
else
  -- свечей нет, идём по своим делам
end


Цитата
Sergey Gorokhov написал:
Вы сейчас про "все данные загружены" или про nil?
Про false
Надо делать так, как надо. А как не надо - делать не надо.
 
Мы же сейчас говорим не про аналоговое телевидение, а про асинхронную передачу дискретного потока данных.
В момент заказа данных есть историчесике данные, это все что есть до этого момента времени. Это срез данных на момент времени. Он один.
Мы начинаем отдавать этот массив. Да, параллельно появляются новые данные. Но в какой-то момент времени мы будем в окрестности границы множества, и в этот момент вы отдаете остаток исторических данных и пришедшее новое (с момента начала передачи) до конца выборки всего массива данных. Опять, это момент, срез времени, с точки зрения наблюдателя он один. Пока не посмотрим на новые данные для наблюдателя их еще нет.

Если Вы говорите, что именно в этот момент пришли новые данных и как-бы данные уже не все, то это как раз не проблема, т.к. это будет уже колбек по новым данным, истрия уже загружена.
 
Anton, написал выше. Я не говорю про "все данные загружены".
Надо делать так, как надо. А как не надо - делать не надо.
 
Цитата
Старатель написал:
nil - это, когда вы запрашиваете DS:Чё_Есть_На_Сервере_Брокера() до того, как клиент получил информацию с сервера. Биты, они, ведь, не мгновенно передаются, понимаете?
В самом определении уже видна логическая ошибка.
Функция которая лезет на сервер для проверки того что есть на сервере, никак не может одновременно смотреть на клиента.
Функция такая взяла залезла на сервер, посмотрела что там есть и вернула клиенту какой-то результат, без какого-либо участия клиента.
false - понятно, на сервере инструмент есть но по нему нет данных
true - тоже понятно, на сервере инструмент есть и по нему данные есть
nil - все еще не понятно, допустим "во всех остальных случаях", включая "инструмента нет", но сразу возникает вопрос, а если инструмент спустя мгновение возьмет и появится? Инструменты же добавляются на сервер не сразу с ходу, а по мере подключения шлюзов
И даже более того, на западных шлюзах инструменты могут появиться прям посреди сессии.
как быть?
 
Цитата
Nikolay написал:
Мы же сейчас говорим не про аналоговое телевидение, а про асинхронную передачу дискретного потока данных.В момент заказа данных есть историчесике данные, это все что есть до этого момента времени. Это срез данных на момент времени. Он один.Мы начинаем отдавать этот массив. Да, параллельно появляются новые данные. Но в какой-то момент времени мы будем в окрестности границы множества, и в этот момент вы отдаете остаток исторических данных и пришедшее новое (с момента начала передачи) до конца выборки всего массива данных. Опять, это момент, срез времени, с точки зрения наблюдателя он один. Пока не посмотрим на новые данные для наблюдателя их еще нет.Если Вы говорите, что именно в этот момент пришли новые данных и как-бы данные уже не все, то это как раз не проблема, т.к. это будет уже колбек по новым данным, истрия уже загружена.

В данном случае, телевидение как раз таки больше всего подходит под пример.
допустим сайт первого канала, там идет online поток трансляции в реальном времени. Вот Вы вдруг захотели скачать от туда информацию.
Сразу возникает проблема того что скачка будет идти вечно.  т.е. нет такого понятия как "все данные загружены"
Если же говорить про архивные данные, то Вы и так уже сейчас можете определить что "все архивные данные загружены" без каких-либо доработок
 
Цитата
Sergey Gorokhov написал:
Функция которая лезет на сервер для проверки того что есть на сервере, никак не может одновременно смотреть на клиента.Функция такая взяла залезла на сервер, посмотрела что там есть и вернула клиенту какой-то результат, без какого-либо участия клиента.
Ничего не понял, что вы тут написали.
Попробую на пальцах схеме:
1) Вызываем CreateDataSource(). Клиент либо создаёт объект, либо сообщает об ошибке. При этом он не только проверяет валидность всех параметров, но и успешность подписки. Под успешность я также понимаю, что в интерфейсе должны также проставиться все галочки: если я запрашиваю параметр, то он должен добавиться в список принимаемых либо сообщить об ошибке.

2) Если data_source создан, то клиент чё-то там отправляет серверу, в ответ последний отправляет клиенту запрашиваемые свечи или флаг, что свечей сервер не имеет.

3) После получения данных с сервера клиент заполняет у себя data_source (если свечи имеются) и флаги true/false.

Ежели мы запросим DS:Чё_Есть_На_Сервере_Брокера() между 2 и 3, то получим nil, потому что флаги ещё не пришли с сервера, про биты помните?

Цитата
Sergey Gorokhov написал:
включая "инструмента нет", но сразу возникает вопрос, а если инструмент спустя мгновение возьмет и появится?
Тут же, вроде, и объект не должен создаваться и CreateDataSource вернёт ошибку, не?
Надо делать так, как надо. А как не надо - делать не надо.
 
Цитата
Sergey Gorokhov написал:
Если же говорить про архивные данные, то Вы и так уже сейчас можете определить что "все архивные данные загружены" без каких-либо доработок
Это какая методика мне позволит узнать, что все исторические данные загружены? При заказе размер 0. И сколько в итоге мы не знаем, пока не загрузим.
 
Цитата
Старатель написал:
Я не говорю про "все данные загружены".
Если речь только о подписке, то да, надо отвечать "нет такого инструмента", а не создавать датасорец в расчете на "мало ли вдруг такой инструмент когда-нибудь появится". А вот с этим
Цитата
то клиент чё-то там отправляет серверу, в ответ последний отправляет клиенту запрашиваемые свечи или флаг, что свечей сервер не имеет.
не согласен в части флага. Пока мы смотрим на датасорец как способ скачать историю, это выглядит логичным, но потом-то датасорец будет поставлять данные без запроса по факту их появления и получится нонсенс: сервер сказал, что данных нет и тут же прислал эти данные. А если ответил флагом нет данных и перестал данные пушить без запроса, вся система вырождается в поллинг, клиент будет с неким периодом переспрашивать, сервер отвечать чаще "нет данных", реже "вот те свечка", и все это с двумя пингами между вопросом и ответом.
 
Скрытый текст
Надо делать так, как надо. А как не надо - делать не надо.
 
По-моему знание "там ничо нет" не дает ровным счетом ничего, оно изоморфно знанию "там ничо нового нет" = "там миллион свечек, но мы их все уже обработали", все равно единственное, что можно сделать дальше, - это вертеться в цикле до второго пришествия (до дисконнекта на самом деле). Ну и надо вертеться значит, раз такой подход выбран, ноль там - ну ок, ноль, continue; одна там свечка - ну ок, одна, сунули ее куда хотели, continue; тысяча их - ну сунули тысячу, continue. Пусть есть функция "чо там у сервера", получили "нет ничо", пошли по своим делам, вернулись, ага, теперь "есть чо", обработали, пошли по своим делам, вернулись... чем отличается от первого варианта? То же самое будет, кстати, если читать файл, в который пишет другой процесс, и это безо всяких квиков и серверов.
 
Anton, задачи, ведь, могут быть разные, как считаете?
Есть, скажем, задача обработать стотыщ графов: отрыть каждый, посчитать чё-то там, закрыть, чтоб память не жрал, выдать результат. Может быть такая задача? Почему нет?
Можно, конечно, работать и в колбеках, наплодить стотыщ data_source и ждать когда Квик рухнет с нехваткой памяти.
Ну это как спорить: как правильно, делать всю работу в main или в колбеках. Нет однозначного ответа. Для каждой задачи нужен свой подход.
Надо делать так, как надо. А как не надо - делать не надо.
 
Цитата
Старатель написал:
Для каждой задачи нужен свой подход.
Тут не поспоришь. В общем-то мой интерес в том, чтобы апи квика сохранялся настолько низкоуровневым, насколько это возможно, и развивался в эту сторону. А это значит, что он должен быть асинхронным, соответственно предложения "а давайте затормозим все и подождем ответа сервера" меня печалят.
 
Цитата
Anton написал:
предложения "а давайте затормозим все и подождем ответа сервера" меня печалят
Меня тоже печалят такие предложения. Но ваш комментарий к этой теме никаким боком не относится.
Надо делать так, как надо. А как не надо - делать не надо.
 
Цитата
Старатель написал:
к этой теме
можно бы предложить возвращать из ds:Size nil вместо нуля, пока с сервера что-нибудь не приехало (хоть бы и ноль). Но сколько народу на это наступит и сколько будет воплей.
 
Цитата
Anton написал:
можно бы предложить возвращать из ds:Size nil вместо нуля, пока с сервера что-нибудь не приехало (хоть бы и ноль).
Три года назад я это предлагал.
Вообще моё предложение, вроде, как не противоречит механизму клиент-серверного общения по протоколу TCP "Запрос-Ответ":
Клиент посылает запрос серверу, тот в ответ либо сразу пушит данные, если они есть, либо отвечает, что данных нет. Пока нет. Они, может быть, и появятся когда-нибудь, но мы этого не знаем.
А что делать с этой информацией вы уже решаете сами.

Скрытый текст
Надо делать так, как надо. А как не надо - делать не надо.
 
Цитата
Старатель написал:
Клиент посылает запрос серверу, тот в ответ либо сразу пушит данные, если они есть, либо отвечает, что данных нет. Пока нет. Они, может быть, и появятся когда-нибудь, но мы этого не знаем.
Так-то мы и без специального уведомления знаем, что данные может когда-нибудь появятся, ну может через неделю, а может и нет. У меня созрела схема получше, давайте попробуем на нее посмотреть. В датасорец добавляем функцию ds:ExpectedSize. Сразу после подписки там nil. Когда сервер что-то посылает по подписке, он также добавляет поле с количеством свечей у него в данный момент. То есть в каждом пакете отправляемом. Как только первый пакет с сервера приехал, это поле становится доступным через ds:ExpectedSize(), далее с каждым пакетом это поле обновляется. Старая ds:Size() продолжает работать как работала, это количество свечей в хранилище у клиента. Что мы получаем в итоге. После подписки, пока ds:ExpectedSize() возвращает nil, мы знаем, что подписка отправлена, но ничего еще не приехало. Потом что-то приехало, пусть одна свечка, ds:Size() дает 1, но ds:ExpectedSize() дает больше, ок, мы знаем, что надо еще подождать. Либо на сервере нет свечей, тогда ds:ExpectedSize() возвращает 0 и мы знаем, что ждать в данный момент больше нечего. Либо мы получили все что есть и ds:ExpectedSize() == ds:Size(), дальше, если хотим реалтайму, никто не запрещает поллить периодически или настроить колбек. В чем-то перекликается с предложениями от Nikolay выше. Правда, не очень представляю, как это будет с тиками работать, они ж по каналу ТВС едут, там свои погремушки.

Цитата
Старатель написал:
И почему ответ OnTransReply на транзакцию может потеряться - сие остаётся загадка.
Дык он не теряется, насколько мне известно, в потоке ответ есть, колбек не дергается почему-то. Может быть потому, что кто ж тогда будет другие продукты покупать.
 
Anton,
https://forum.quik.ru/messages/forum10/message22935/topic2397/#message22935

Проблема в том, что Sergey Gorokhov, не понимает, что данные по сетям передаются не мгновенно, требуется какое-то время, пока клиент их получит. Конечно, откуда ему знать, он же в одной сети со своим игровым сервером QUIK Junior сидит. У него всё приходит, как с локального сервера, быстрее, чем он может подумать. Да и нет там такого объёма трафика, чтобы были задержки какие-то.
Вот и говорит Sergey Gorokhov, вот вам ds:Size(). Если там ноль, значит свечей нет. И невдомёк ему, что в реальном мире всё не так. А пока Sergey Gorokhov, предложение не одобрит, оно не будет принято. Модератор, однако.
Надо делать так, как надо. А как не надо - делать не надо.
 
Цитата
Старатель написал:
не понимает
Все он понимает, но ему-то придется думать, как минимум, как эту схему на тики распространить. Я вот не придумал так сходу. Пока не будет точно ясно, скока вешать в граммах, будут общие фразы "когда-нибудь рассмотрим и подумаем". Когда что-то четко формулируется, они сразу же это и делают. Соответственно если хотим что-то получить, надо это что-то обсосать до реализуемого вида, подход "мне все равно как вы будете делать" работает против пожелателя, бо раз все равно, то "никак" тоже вариант.
Страницы: 1 2 След.
Читают тему
Наверх