isConnected и пара неприятных моментов

Страницы: 1
RSS
isConnected и пара неприятных моментов
 
Может, я что-то не до конца понимаю, и мне кто-нибудь прояснит ситуацию по приведённым ниже пунктам.

1) isConnected(), конечно, хорошая функция, но мне кажется, что её корректное использование таково: если она вернула 0, то разработчик может предусмотреть запрет на выполнение каких-то действий в скрипте, поскольку информация в терминале не соответствует действительности (устарела). А вот если isConnected() вернула 1, то это ничего не гарантирует: может, нужные шлюзы ещё не подключены, может информация не до конца загрузилась с сервера. Т.е. мы можем избежать гарантированных ошибок при isConnected() == 0, но не сделать ошибок при  isConnected() == 1 эта функция не помогает.

2) При разрыве соединения и повторном подключении терминала к серверу в какой-то момент происходит пропадание информации в ТТТ (и других) и её повторное появление. При работе скриптов в момент "пропадания" информации справочные функции типа getSecurityInfo() могут вернуть пустые таблицы. Это приводит к тому, что скрипт, скажем, читает информацию о размере лота, а там его нет. Неприятно.

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

Может кто поделиться своим опытом по данному поводу? Из каких ещё функций, кроме getSecurityInfo(), будут получаться пустые таблицы в моменты перезагрузки данных? Могут ли разработчики прокомментировать это (и отразить в документации, что возвращается, если нет данных)?
 
Я понимаю, что нельзя гарантировать, что в терминале есть вся последняя информация с биржи. Но трудно писать код, когда ты проверил в if условие, что всё должно быть хорошо, а после then всё сразу стало плохо (ситуация поменялась). Нет атомарности.

Вот и приходится без проверки всяких условий isConnected() делать какой-нибудь getXXX(), а потом проверять заполненность полей таблицы внутри результата, потому, что с очень малой вероятностью "что-то пошло не так".
 
Здравствуйте, _sk_!
К сожалению, достоверно понять, что данные актуальны, нельзя. Точно так же, как и понять, что разрыва соединения в момент выполнения той или иной функции не произошло, так как неизвестно в какой именно момент случится то или иное событие (разрыв соединения, авария в торговой системе, отключение шлюза и так далее).
Подобные вопросы обсуждались уже неоднократно, например, в этой ветке: https://forum.quik.ru/forum10/topic5836/
QUIK clients support
 
Цитата
_sk_ написал:
По второму пункту хотелось бы понять, как избежать постоянных проверок, что информация отсутствует.
Можно в OnConnected проверить список доступных классов getClassesList() и, если нужный класс ещё не загружен, то не дёргать getSecurityInfo вообще.
Но конкретно с бумагой сложнее: информация по бумаге может загрузиться в любой момент без уведомления.

Цитата
_sk_ написал:
Возможно, что при перезагрузке данных в таблицах имеет смысл блокировать запросы к функциям типа getSecurityInfo(), пока они не могут вернуть данные. Пусть скрипты подождут на этой блокировке.
Вы и сами это можете сделать тупым зацикливанием с постоянной проверкой возвращаемого результата от функции. Но есть вероятность зависнуть тут навсегда.
Надо делать так, как надо. А как не надо - делать не надо.
 
Цитата
_sk_ написал:
Нет атомарности.
А ее и нет как таковой в реальности. Во-первых, мы, как астрономы, наблюдаем свет давно потухших звезд, только у тех световые годы, а у нас сетевые пинги. Во-вторых, оно все и на бирже не в одно ядро происходит, то есть буквально в неопределенном порядке. Был бы некий лок всей биржи, было бы здорово. Остановил время, осмотрелся, сделал что надо, запустил дальше. Но мы можем только сами создать себе "атомарность" путем сериализации событий и в каждый момент времени считать, что вот эта наша "последовательность восприятия" истинная и есть, учитывая, конечно, все вытекающие. На первый взгляд сериализация ничего не дает, но на самом деле у нас всегда одно конкретное состояние, пусть даже и не отражающее текущую действительность. Без сериализации вместо состояния имеем только его "волновую функцию". Например, отправили заявку на 100 лотов, сколько исполнено в данный момент? Приехало вроде "исполнено 3", но это было пинг назад, а может прямо сейчас уже 10, а может и все 100. Заявка Шредингера, ага. На самом деле весь мир таков, мы просто привыкли и не замечаем. Пошел за хлебом, а хлеба нет. Вчера в это время был, и позавчера был, а тут раз и нет. Волновая функция сколлапсировала не там, где обычно.
 
Все же волновая функция - это про вероятность. У нас же есть пакеты данных и, теоретически, каждый пакет обладает информацией, что он несет. Как накладная на груз.
Поэтому мы могли бы понимать, что последнее, что мы получили - это такие-то данные. Либо мы просто ждали бы пакет с таким типом данных, фильтруя другие. Да, мы не знаем последние ли это данные, справедливо. Но и понятие "последние" не применимо здесь. я бы назвал их текущие. Но они бы были не обезличенные.
Также пакет мог бы нести данные о смысле этих данных - справочник, очистка таблицы, заполнение таблицы, информация о цене сделки и т.д., и, скорее всего, несет. Часть этого есть в колбеках, но явно недостаточная.

А вот с точки зрения времени - да, у нас полная неопределенность. Но, как мне кажется, обладай бы мы полной информацией о смысле полученных данных, ошибках сервера (читай больше колбеков) в данный момент - это было бы не столь критично.


В соседней ветке написал про открытие рынка с утра, когда вдруг позиция становится 0, а тут же опять корректная. Т.е. явно идет либо очистка данных (был вызван CleanUp), чтобы далее получить новые, либо некий пакет данных, содержащий неполную, либо "технологическую" информацию, а скрипт в этот момент времени измерил состояние. Я к сожалению не выводил в лог полную таблицу future_client_holding, так бы было ясно что-то: пустая она, неполная и т.д.  
 
Цитата
Nikolay написал:
обладай бы мы полной информацией о смысле полученных данных, ошибках сервера (читай больше колбеков) в данный момент
Так и квик об ошибках сервера вряд ли знает. А биржевую инфу как только увидит, тут же дернет ваш колбек, даже раньше, чем сам инфой попользуется. С тем же клинапом, увидел квик новый идентификатор сессии и дернул OnCleanUp, потом почистил свои таблицы (тут вы ноль и поймали) и стал ждать, чего там нового приедет. Он бы может и рад вам сообщить что-нибудь еще, да сам не знает ничего. То же самое и сервер, ему от биржи приехало что-то, он это упаковал и отправил, он не знает, там еще очередь стоит или это последнее на сегодня и дальше будет только новая сессия в понедельник утром. В плане больше колбеков это да, еще несколько штук не помешало бы, да и существующие если бы чутка иначе работали и кое-какие гарантии давали, было бы удобнее. Тот же клинап если бы гарантировал, что вся предыдущая сессия, как она была сохранена, еще в полном виде имеется, было бы очень здорово. Равно как и после очистки если б что-нибудь дергалось с гарантией, что квик пустой от слова совсем.
Страницы: 1
Читают тему
Наверх