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

Страницы: Пред. 1 2
RSS
Createsource и смена сессии
 
Скрытый текст

Скрытый текст

Цитата
Anton написал:
как эту схему на тики распространить.
А что с тиками не так?
Надо делать так, как надо. А как не надо - делать не надо.
 
Вот для примера сколько идет заказ данных интервала минута

[Fri Jun 19 11:00:35 2020 4938.594] SiU0 SPBFUT size 0
[Fri Jun 19 11:00:35 2020 4938.634] SiU0 SPBFUT size 0
[Fri Jun 19 11:00:35 2020 4938.655] SiU0 SPBFUT size 0
[Fri Jun 19 11:00:35 2020 4938.676] SiU0 SPBFUT size 0
[Fri Jun 19 11:00:35 2020 4938.697] SiU0 SPBFUT size 0
[Fri Jun 19 11:00:35 2020 4938.718] SiU0 SPBFUT size 0
[Fri Jun 19 11:00:35 2020 4938.739] SiU0 SPBFUT size 0
[Fri Jun 19 11:00:35 2020 4938.76] SiU0 SPBFUT size 65596
[Fri Jun 19 11:00:35 2020 4938.781] SiU0 SPBFUT size 65596
[Fri Jun 19 11:00:35 2020 4938.802] SiU0 SPBFUT size 65596

т.е. 200 мс я имею 0 в качестве размера, а потом сразу резко весь размер. Можно, конечно, предположить, что если число отлично от 0, то все загружено, но в марте когда была сильная волатильность и сервера висели, получались и промежуточные числа.

С тиками еще сложнее - их много пройдет после заказа данных и до "окончания" загрузки.

В связи с этим хотелось бы понять: первый size отличный от 0 - это что? Как его интерпретировать?
 
Цитата
Старатель написал:
А что с тиками не так?
Они едут в ТВС всей (заказанной) толпой, по отдельным датасорцам их клиент должен разбирать, так что серверу тут нечего отправить в качестве текущего количества свечей по конкретному тикеру. Можно даже предположить, что он и по всей ТВС затруднился бы сказать, сколько у него тиков в моменте.

Цитата
Старатель написал:
Имитация разрыва соединения с сервером
Тут как раз логично выглядит. Для клиента отправленная транзакция закончилась дисконнектом, а в новом подключении клиент обнаружил неизвестно откуда взявшийся ордер, может его руками поставили с другого клиента. Скорей вопрос, почему квик после команды дисконнекта позволяет еще что-то отправить. Очевидно, дело в том, что мейн успевает пропихнуть транзакцию, пока основной поток в неопределенном состоянии. На досуге поковыряю тему, может что не так понял чисто по коду. Я про другое говорил, когда на некоторые транзакции вообще колбека нет (без потери соединения).
 
Цитата
Anton написал:
Тут как раз логично выглядит.
Не вижу логики. Сервер отправляет ответ по транзакции автору этой транзакции, а не другому клиенту. Если сервер не повторил отправку неподтверждённого пакета, то вопрос к серверу, почему? Если же это клиент получил, но не вызвал колбек, - то к клиенту.
Цитата
Anton написал:
Скорей вопрос, почему квик после команды дисконнекта позволяет еще что-то отправить.
У меня больше вопрос, почему, если поставить sleep побольше и транзакция не успевает отправиться до дисконекта, то нет сообщения об ошибке. Скорее всего, sendTransaction только проверяет валидность параметров и доступность указанной транзакции и сразу возвращает результат этой проверки, а саму транзакцию ставит в очередь на отправку. А когда доходит до отправки, то уже дисконект. Но в этом случае клиент должен уведомить, хотя бы вызовом того же OnTransReply с соответсвующим сообщением.

Цитата
Nikolay написал:
С тиками еще сложнее - их много пройдет после заказа данных и до "окончания" загрузки.
В связи с этим хотелось бы понять: первый size отличный от 0 - это что? Как его интерпретировать?
На рабочее место загружено такое-то количество свечей. По другому - никак.
Я и не настаиваю на интерпретации "окончания загрузки". Об "окончании загрузки" можно с уверенностью говорить только по завершении торгов, когда известно, что свечей не прибавится.
Дадут ds:ServerSize() будем с ним работать )) Вариант
Код
while ds:Size() ~= ds:ServerSize() do sleep end
тоже вполне рабочий для определённых целей.

Цитата
Anton написал:
Они едут в ТВС всей (заказанной) толпой, по отдельным датасорцам их клиент должен разбирать, так что серверу тут нечего отправить в качестве текущего количества свечей по конкретному тикеру. Можно даже предположить, что он и по всей ТВС затруднился бы сказать, сколько у него тиков в моменте.
Серверу ведь не составило бы труда посчитать каждый тик по приходу и положить результат на полочку, если он уже этого не делает.
Надо делать так, как надо. А как не надо - делать не надо.
 
Цитата
Sergey Gorokhov написал:
Функция которая лезет на сервер для проверки того что есть на сервере, никак не может одновременно смотреть на клиента.Функция такая взяла залезла на сервер, посмотрела что там есть и вернула клиенту какой-то результат, без какого-либо участия клиента.
Кажется, я понял. Sergey Gorokhov, похоже, вы думаете, что ds:Size() напрямую обращается к серверу. Поверьте, это не так. Size() возвращает то количество свечей, которое получил и для него посчитал клиент на месте и участливо положил в датасорс. Можете спросить у старших.
Надо делать так, как надо. А как не надо - делать не надо.
 
Цитата
Старатель написал:
Если сервер не повторил отправку неподтверждённого пакета, то вопрос к серверу, почему?
Думаю, сервер получил от шлюза уведомление, ткнулся его переслать клиенту, а там дисконнект. И выбросил. Гарантированная доставка это что-то типа MQ, сомневаюсь, что в квике так сделано.

Цитата
Старатель написал:
Скорее всего, sendTransaction только проверяет валидность параметров и доступность указанной транзакции и сразу возвращает результат этой проверки, а саму транзакцию ставит в очередь на отправку.
Скорее всего да, но в данном случае не должен был делать ничего, кроме возврата ошибки, поскольку уже инициирован дисконнект. Тут опять дело в синхронизации, видимо. Квик мог бы все запросы от скриптов и нижнего уровня пропускать через SendMessage главному потоку, так что при обработке любого сообщения состояние было бы всегда консистентным без всякой дополнительной синхронизации. Но это было бы узкое место во всей системе. Судя по всему, часть операций скрипт выполняет, непосредственно дергая апи нижнего уровня, мимо главного окна (и его потока), равно как и нижний уровень сначала меняет состояние, а потом уведомляет главный поток сообщением. И в результате получается рассинхрон, как в этом примере, главное окно считает, что оно инициировало дисконнект, а скрипт и нижний уровень еще вовсю транзакции пуляют.
 
Цитата
Anton написал:
Думаю, сервер получил от шлюза уведомление, ткнулся его переслать клиенту, а там дисконнект. И выбросил.
Согласен, пример неудачный, дисконект. Потом - новая сессия, пакеты прошлой сессии не в счёт.
Надо делать так, как надо. А как не надо - делать не надо.
 
Старатель,
Простите но Вы говорите ерунду и перемешиваете одни ситуации с другими вообще не понимая между ними разницы.
Это так к слову.
Если по делу, у Вас есть конкретное предложение по введению функции.
И суть этого предложения как раз и вызывает вопросы.
В том числе, чем оно отличается от предложения зарегистрированного 3года назад.
Если ничем, то и регистрировать повторное пожелание не имеет смысла.
 
Цитата
Sergey Gorokhov написал:
И суть этого предложения как раз и вызывает вопросы.
К сожалению, у вас так и останутся вопросы пока, наконец, вы не поймёте, что ds:Size() не обращается напрямую к серверу, а возвращает количество свечей на рабочем месте.

Цитата
Sergey Gorokhov написал:
чем оно отличается от предложения зарегистрированного 3года назад.
Признаться, я уже и запамятовал, что там регистрировалось 3 года назад. Случайно вчера наткнулся на старую тему.
Надо делать так, как надо. А как не надо - делать не надо.
 
Цитата
Старатель написал:
К сожалению, у вас так и останутся вопросы пока, наконец, вы не поймёте, что ds:Size() не обращается напрямую к серверу, а возвращает количество свечей на рабочем месте.

Вот именно что ds:Size() не обращается напрямую к серверу.
И как раз таки именно Вам надо это понять.
ds:Size смотрит что в терминале и как раз таки для решения задачи проверки полученных данных ее и надо использовать, ровно это Вы и делаете.
Вы же предлагаете добавить не проверку полученных данных, а того что есть на сервере, даже Ваша функция так названа "Чё_Есть_На_Сервере_Брокера"
А теперь еще раз прочитайте что я Вам сказал:
Цитата
Функция которая лезет на сервер для проверки того что есть на сервере, никак не может одновременно смотреть на клиента.

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

В связи с чем возникает резонный вопрос, в какой ситуации сервер (именно сервер а не терминал) должен ответить nil функции "Чё_Есть_На_Сервере_Брокера" на ее запрос?
И Вы так и не дали вразумительного ответа на этот вопрос.

забудьте вообще про клиента, поставьте себя на место сервера.
К серверу пришел запрос на data_source, он отправляет клиенту ответ в виде кучи запрашиваемых свечек или пусто если свечей нет.
Понятно что отправка занимает время, но со стороны сервера это сотые доли секунд, дальше весь путь занимает сеть до клиента и т.п.
Допустим до клиента весь пакет еще не дошел и сервер получил запрос "Чё_Есть_На_Сервере_Брокера", по Вашей логике он должен вернуть nil т.к. до клиента полный пакет еще не дошел.
Но от куда сервер должен знать что до клиента пакет не дошел? Да ни от куда, потому что клиент не сообщает серверу что он получил пакет. Связь в этом месте односторонняя.
Следовательно сервер не сможет в описанной ситуации ответить nil.

Ровно это и имелось ввиду под фразой из моей цитаты.
ну не может запрос на сервер одноременно смотреть на клиента.
 
Цитата
Sergey Gorokhov написал:
В связи с чем возникает резонный вопрос, в какой ситуации сервер (именно сервер а не терминал) должен ответить nil функции "Чё_Есть_На_Сервере_Брокера" на ее запрос?
Так, писать вы научились. Теперь учитесь читать:

Цитата
Старатель написал:
2) Если data_source создан, то клиент чё-то там отправляет серверу, в ответ последний отправляет клиенту запрашиваемые свечи или флаг, что свечей сервер не имеет.
Или количество свечей на сервере (вместо флага) в предыдущей редакции. (Ну запамятовал я, что такое пожелание уже было.)

Цитата
Старатель написал:
3) После получения данных с сервера клиент заполняет у себя data_source (если свечи имеются) и флаги true/false
А до получения данных - нечего возвращать, там пусто, nil, понимаете?

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

Если так не понятно, я не знаю, как ещё объяснить.
Вот человек постарался расписал для самых маленьких, читайте, может поймёте откуда nil.
Надо делать так, как надо. А как не надо - делать не надо.
 
Цитата
Anton написал:
Либо на сервере нет свечей, тогда ds:ExpectedSize() возвращает 0 и мы знаем, что ждать в данный момент больше нечего. Либо мы получили все что есть и ds:ExpectedSize() == ds:Size(), дальше, если хотим реалтайму, никто не запрещает поллить периодически или настроить колбек. В чем-то перекликается с предложениями от  Nikolay  выше.
Anton, я вот тут подумал, это тогда, когда клиент хранил историю в 3000+ свечей количество свечей на сервере могло пригодиться. Сейчас, когда сервер хранит 3000+, а клиент 65 тыс. количество свечей на сервере не особо то поможет, скорее навредит. Важен только сам факт есть там свечи или нет.
Надо делать так, как надо. А как не надо - делать не надо.
 
Старатель, если я правильно понимаю Ваше пожелание, то это прямой серверный вызов. Но это принесет много проблем.
Сейчас у нас вызовы синхронный, мы получаем ответ сразу, т.к. берем это из кеша терминала. Ответ приходит после проверок на клиенте.
Ваше же предложение просто не поддерживается сейчас языком от слова совсем. Если попробовать использовать синхронный вызов к серверу, то это пусть в никуда, т.к. пока не пришел ответ, что делать коду?

Вы ввели команду x = ServerX()

И что? Все, код встал? Ответ же не ясно когда придет. Поэтому такие вызовы делают асинхронными. А у нас их нет. Это потребует разработки функциональнсти типа async-await, promice и т.д.

Потом, если разобрать запрос CreateDataSource, то это же простой заказ данных, не получение. Он возвращает nil, если не прошла проверка на входящие параметры. Т.е. нет такого потока и нечего ждать.
Size - это число баров. Оно тоже не может быть nil, т.к. если их нет, то это 0. А что такое nil баров, если проверка на корректность потока прошла? Нам остается только определить ситуации когда есть некая ошибка получения данных по заказанному потоку данных и метод, определяющий, что мы еще в процессе передачи исторических данных, т.к. их может быть много.

Я как раз говорю про методы определения состояния потока, а не прямое обращение к серверу. Это, на самом деле, не самое лучшее решение делить контексты вызовов. Ваш код превратится в кошмар. Придется использовать аннтотации - это сервер, это клиент. Здесь ждать, здесь сразу.

Конечно было бы хорошо иметь возможность задать что-то типа такого: CreateDataSource(class, code, i, callBack)

где callBack - это ссылка на функцию или лямбда. Тогда такой вызов станет асинхронным и получив ответ, принимать какие-то решения.
Это же относится и к остальным "как-бы" серверным вызовам, в частности отправка транзакции. Я бы предпочел получить гарантированный асинхронный ответ вызова, чем искать его в потоке смешанных ответов.

Текущая схема колбеков просто не дает их использовать, если нужна гарантия получения ответа.
 
Цитата
Nikolay написал:
Старатель, если я правильно понимаю Ваше пожелание, то это прямой серверный вызов.
Не правильно. Ответ тот же, что и для Sergey Gorokhov, читайте выше:
https://forum.quik.ru/messages/forum10/message46438/topic5543/#message46438

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

Псевдокод, OnParam взят только в качестве иллюстрации:
Цитата
DS = {
 ['есть чё?'] = nil,
 SuperFunc = function(self)
   return self['есть чё?']
 end
}

function main()
 while DS:SuperFunc() == nil do
   -- Ждём пока сервер ответит
   sleep(1000)
 end
 message('Ответ получен: ' .. DS:SuperFunc())
end

function OnParam()
 -- Сервер ответил, заполняем DS
 DS['есть чё?'] = 'есть'
end
Так понятнее?
Надо делать так, как надо. А как не надо - делать не надо.
 
И вдогонку (учитывая опыт), а то опять не поймёте: то что написано в OnParam, заполнение нашего поля, делает естественно сам терминал по приходу ответа от сервера на запрос CreateDataSource, мы ведь об нём тему мусолим.
Надо делать так, как надо. А как не надо - делать не надо.
 
Цитата
Старатель написал:
Сейчас, когда сервер хранит 3000+, а клиент 65 тыс. количество свечей на сервере не особо то поможет, скорее навредит.
Да, об этом не подумал. Тогда остается что, а остается ничего, сам факт приезда (первого) пакета на клиент только. Даже и функции много, флажок в датасорце, "ответ сервера получен". В сухом остатке что тогда от арки требуется: 1) убедиться, что сервер всегда что-нибудь отвечает на подписку, есть ли данные или нет; 2) на клиенте по получении первого ответа поставить флажок в датасорце.
 
Цитата
Nikolay написал:
Size - это число баров. Оно тоже не может быть nil, т.к. если их нет, то это 0. А что такое nil баров, если проверка на корректность потока прошла?
Вам сюда.

И второй вариант:
Код
DS = {
  ['есть чё?'] = nil,
  SuperFunc = function(self)
    return self['есть чё?']
  end
}

function main()
  while DS:SuperFunc() == nil do
    -- Ждём пока сервер ответит
    sleep(1000)
  end
  message('Ответ получен: ' .. DS:SuperFunc())
end

function OnParam()
  -- Сервер отвечает:
  -- Свечей не имею, но, ежели, они когда появятся, я вам маякну, если подписка не будет закрыта,
  -- а пока пишем:
  DS['есть чё?'] = 'нет ничё'
end
Надо делать так, как надо. А как не надо - делать не надо.
 
Кстати говоря, при наличии флажка таки сохраняется вариант зависнуть навеки в цикле, если первым придет дисконнект. Все же поллинг зло как ни крутись.
 
Старатель, если Вы не можете объяснить свою идею, то это Вам не поможет. Мне без разницы в какой манере Вы отвечаете, просто буду пропускать сообщения.
Что, наверно, сделают и представители разработчика.

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

Ваша фнкция DS:Чё_Есть_На_Сервере_Брокера() обращается к справочной информации, т.к. Вы просто хотите получить данные о признаке наличия данных, а не их количестве. Эта информация итак приходит вместе со всеми информационными таблицами. Технически, сейчас просто нет информации о наличии баров по каждому интервалу. Есть, допустим, информация о Статусе инструмента, его классе и т.д., а по барам нет. Ваш псевдокод как раз и организует подписку на получение этих данных.

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

Также вызникает вопрос: Если CreateDataSource вернул нам объект. т.е. запрос был корректным, инструмент правильный, интервал правильный (сейчас правда не проверяют это, но надеюсь это исправят) - значит бары есть. Если их 0, то что? Не было торгов? Сервер брокера сломался? Вы же не просите тип ошибки: 404 или 204 и д.р.. А я как раз хотел бы видеть коды ответа сервера. А не просто ничего нет на сервере. Если CreateDataSource выполнился, значит информация есть в локальном кеше. Как же она к нам попала, если на сервер ничего нет.
Цитата
честный ответ: если сервер ещё ничё не прислал, то и ответ будет буквально "ничё", nil. Ежели с сервера уже получили ответ, то там будет признак наличия/отсутствия свечей на сервере.
Если сервер ничего не прислал, то это не значит, что там ничего нет - это значит, что идет процесс передачи, обработка запроса. А если с сервера получили ответ, что там не свечей, то такое может быть только если их физически нет (первый день торгов) или ошибка базы данных или что-то еще. Так вот и надо различать эти состояния. В одном случае это не помешает мне анализировать инструмент, а в другом я просто выкину исключение, чтобы не возвращаться более к нему. А в третьем, я увижу статус: в процессе и буду ждать колбек о приходе данных, не дергая постоянно функцию.
 
Nikolay, не могу похвастаться уровнем работы с высокими материями, новичёк ещё. Поэтому, если позволите, взгляд со стороны, неопытного программиста.

Цитата
Nikolay написал:
Ваша фнкция DS:Чё_Есть_На_Сервере_Брокера() обращается к справочной информации, т.к. Вы просто хотите получить данные о признаке наличия данных, а не их количестве. Эта информация итак приходит вместе со всеми информационными таблицами.
Не хватает признака отсутствия данных, мы об этом.
Цитата
Nikolay написал:
Вы просто хотите получить данные о признаке наличия данных, а не их количестве.
Хотите туда количество? Да, пожалуйста, просите разработчиков. Как будете использовать - ваше дело.

Цитата
Nikolay написал:
Если CreateDataSource выполнился, значит информация есть в локальном кеше. Как же она к нам попала, если на сервер ничего нет.
Конечно, информация есть, как минимум список классов, но не обязательно график.
Чтоб вы понимали, как это работает (на примере графика цены и объёма):
Когда вы вызываете CreateDataSource, она проверяет валидность класса, и, в случае успеха, тут же выплёвывает вам data_source. Причём, возможны несколько вариантов:
1) Если график уже открыт, то CreateDataSource сразу выдаст вам заполненный data_source.
Если график не открыт, то:
2) Если клиент оффлайн и находит в кеше нужный бинарник, то в data_source будут свечи из этого бинарника.
3) Если клиент оффлайн и графика в кеше нет, то data_source будет пустой (Size = 0).
4) Если клиент онлайн, то data_source будет пустой (Size = 0) до тех пор, пока не получит хоть одну свечу.

Цитата
Nikolay написал:
Если их 0, то что? Не было торгов?
Может, не было, а может, было, не узнаешь, пока не пройдёт хоть одна сделка. См. выше, четвёртый пункт.

Цитата
Nikolay написал:
тип ошибки: 404 или 204 и д.р.. А я как раз хотел бы видеть коды ответа сервера. А не просто ничего нет на сервере.
Здравая мысль, просите разработчиков. Но, насколько мне известно, до недавнего времени у сервера отсутствовала функция мониторинга "почему сломался график." Не знаю, может, появилось что-то.

Цитата
Nikolay написал:
Если сервер ничего не прислал, то это не значит, что там ничего нет - это значит, что идет процесс передачи, обработка запроса.
А кто с этим спорит? Мы пока не знаем, что "там" есть.
Надо делать так, как надо. А как не надо - делать не надо.
 
Цитата
Nikolay написал:
Только вот использование этой функции будет таким же неудобным, т.к. придется писать постоянный вызов этой функции, Вы же не значете когда придет ответ. Это синхронный подход. Он плохо работает.
Наличие флага "ответ от сервера получен" не лишает вас возможности использовать колбек.
Надо делать так, как надо. А как не надо - делать не надо.
 
Цитата
Anton написал:
Тогда остается что, а остается ничего, сам факт приезда (первого) пакета на клиент только. Даже и функции много, флажок в датасорце, "ответ сервера получен". В сухом остатке что тогда от арки требуется: 1) убедиться, что сервер всегда что-нибудь отвечает на подписку, есть ли данные или нет; 2) на клиенте по получении первого ответа поставить флажок в датасорце.
Тоже хороший вариант.

Скрытый текст
Надо делать так, как надо. А как не надо - делать не надо.
 
Цитата
Anton написал:
Даже и функции много, флажок в датасорце, "ответ сервера получен".
Если быть точным, то флажок в userdata, на который ссылается объект ds._DataSource. Этот флажок надо из _DataSource как-то получить, - нужна функция.
Надо делать так, как надо. А как не надо - делать не надо.
 
Цитата
Старатель написал:
Приходится либо снимать дубликаты, либо работать в main с неопределённой задержкой.
Есть еще вариант пульнуть фейковый стоп по нереальной цене и подождать ответа, тксть протолкнуть им. И снять тут же, конечно. Фактически сымитировать тот самый флаг "ответ приехал". Но датасорец, конечно, так не протолкнешь.
 
Цитата
Anton написал:
Тогда остается что, а остается ничего, сам факт приезда (первого) пакета на клиент только. Даже и функции много, флажок в датасорце, "ответ сервера получен". В сухом остатке что тогда от арки требуется: 1) убедиться, что сервер всегда что-нибудь отвечает на подписку, есть ли данные или нет; 2) на клиенте по получении первого ответа поставить флажок в датасорце.
Проверил. При запросе данных (открытием графика али через скрипт) сервер в любом случае отвечает клиенту, даже если свечей нет.

Можно ли тут обратиться к компетентным сотрудникам/разработчикам минуя первую линию защиты поддержки?
Надо делать так, как надо. А как не надо - делать не надо.
 
Цитата
Старатель написал:
Цитата
Anton написал:
Тогда остается что, а остается ничего, сам факт приезда (первого) пакета на клиент только. Даже и функции много, флажок в датасорце, "ответ сервера получен". В сухом остатке что тогда от арки требуется: 1) убедиться, что сервер всегда что-нибудь отвечает на подписку, есть ли данные или нет; 2) на клиенте по получении первого ответа поставить флажок в датасорце.
Проверил. При запросе данных (открытием графика али через скрипт) сервер в любом случае отвечает клиенту, даже если свечей нет.

Можно ли тут обратиться к компетентным сотрудникам/разработчикам минуя первую линию  защиты  поддержки?
Добрый день,

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

Цитата
Anton написал:
флажок в датасорце, "ответ сервера получен". В сухом остатке что тогда от арки требуется: 1) убедиться, что сервер всегда что-нибудь отвечает на подписку, есть ли данные или нет; 2) на клиенте по получении первого ответа поставить флажок в датасорце.
Цитата
Старатель написал:
Вообще такого флага не хватает во многих таблицах терминала.
например, stop_orders, money_limits, depo_limits
Надо делать так, как надо. А как не надо - делать не надо.
 
Цитата
Egor Zaytsev написал:
Вы можете написать вопрос здесь, обязательно он будет отвечен.

Похоже, сообщение не дошло до адресата.

Надо делать так, как надо. А как не надо - делать не надо.
 
Старатель, Anton, здравствуйте.

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

Цитата
s_mike@rambler.ru написал:
Странно, что терминал выдает успех на cresteddatasource, если реальная подписка не осуществлена.
Описанная в данном инциденте ошибка была исправлена в версии 8.13.0 терминала QUIK.
Рекомендуем обновить версию программы.

Приносим извинения за причиненные неудобства.
Страницы: Пред. 1 2
Читают тему
Наверх