Quik перестает соединяться с серверами

Страницы: 1
RSS
Quik перестает соединяться с серверами
 
Версия терминала 6.16
Настройки в "Доступные соединения" вот такие.
http://i.imgur.com/qVOGULE.png
Всегда такие. Уже много лет. С терминалом работаю много и долго, не новичок.
Но вот начал недавно наблюдать следующее - после выходных, в понедельник застаю терминал без соединения с сервером. При этом он даже не пытается соединяться. Последняя попытка соединения в 9ч47м субботы.
Ручной запуск соединения "жмак ключик" тут же запускает соединение.
Что делать? Ведь так не должно быть с моими настройками?
 
Добрый день.

Уточните, в пятницу перед завершение работы в Quik вы соединение разрываете самостоятельно
или оставляете программу подключенной к серверу?
 
Егор,
терминал работает без выключения когда-либо. В течении рабочей недели соединяется по утрам с серверами без проблем, но, судя по последнему сообщению, "спотыкается" об неудавшееся соединение субботу утром и в понедельник уже не пытается соединяться. Помогает только ручное соединение "ключиком", после чего работает всю неделю без проблем. До следующей "подлой субботы" и "черного понедельника". )
 
Брокер ПСБ.
 
Цитата
green_X5 пишет:
Брокер ПСБ.
Цитата
green_X5 пишет:
Егор,
терминал работает без выключения когда-либо. В течении рабочей недели соединяется по утрам с серверами без проблем, но, судя по последнему сообщению, "спотыкается" об неудавшееся соединение субботу утром и в понедельник уже не пытается соединяться. Помогает только ручное соединение "ключиком", после чего работает всю неделю без проблем. До следующей "подлой субботы" и "черного понедельника". )
Добрый день.

Будем пытаться воспроизвести. Вернемся, как будет информация.
 
нет. не вернётесь - вы ж на тестовых серверах тестите. https://forum.quik.ru/messages/forum10/message4019/topic444/#message4019
 
Цитата
sam063rus пишет:
нет. не вернётесь - вы ж на тестовых серверах тестите.
Объясните какое это имеет значение в данном конкретном случае.
 
Сергей, доброй у Вас наверное уже ночи,
ну проявите проф. выдержку,  это же форум, как говорил известный полководец - "В бой с мелкими группировками не вступать, только вперед!" :)
 
Понаблюдал, проблема не повторяется, наверное можно закрывать это обращение.
Это походу серверы брокера ПСБ чудеса вытворят. Сегодня например с утра выдавал жуткие данные по инструментам с утра, и не мне одному, всем клиентам. С помощью техподдержки брокера разобрались, но пожалуй нужно в скрипты ещё кучу защит от такого идиотизма брокерских серверов прописывать.
 
Цитата
green_X5 пишет:
Сегодня например с утра выдавал жуткие данные по инструментам с утра
Цитата
green_X5 пишет:
но пожалуй нужно в скрипты ещё кучу защит от такого идиотизма брокерских серверов прописывать
Не могли бы вы подробней написать, что там жуткого выдавалась? Я, конечно, стараюсь везде ставить проверку на соответствие адекватным значениям, но вдруг чего-нить пропустил.
Надо делать так, как надо. А как не надо - делать не надо.
 
С самого утра вообще никаких параметров бумаг, совсем ничего. пустые поля в таблицах. Потом цены пошли, но у текущих фьючей "до погашения" ноль дней. Хотя жить им ещё 28. Просто офигенно, у меня бот автоматом меняет бумаги перед экспирацией! Благо позиция бота была нулевая.
 
постоянно такой "дефект" заметен. Уже задавали вопросы на форуме - ответ (если подитожить) - был один. квик не знает: все ли данные уже прогруженны и с какого начального момента начинать обновление. возможно со всем этим какую-то роль играет вариация параметров на тему получения пропущенных данных.
 
в любом случае, если всё, как и написано выше - то это однозначно "косяк" квика. и пусть тут даже не кивают на биржу бо как на то и торговый терминал, чтоб это отслеживать.
 
Цитата
green_X5 пишет:
С самого утра вообще никаких параметров бумаг, совсем ничего. пустые поля в таблицах.
Здравствуйте,
С самого утра информации нет, так как на сервер информация еще не поступала. Торговая система работает по расписанию, если шлюзы будут запущены до старта ТС то в QUIK Вы данные не увидите.
Цитата
green_X5 пишет:
Потом цены пошли, но у текущих фьючей "до погашения" ноль дней. Хотя жить им ещё 28.
Так не должно быть. Пришлите скриншот на котором видно проявление проблемы дату и инструмент
 
Цитата
Sergey Gorokhov пишет:
Цитата
green_X5 пишет:
Потом цены пошли, но у текущих фьючей "до погашения" ноль дней. Хотя жить им ещё 28.
Так не должно быть. Пришлите скриншот на котором видно проявление проблемы дату и инструмент
День добрый, Сергей.
К сожалению, скриншот уже поздно делать. Судорожно набирал тех.поддержку брокера (я активно торгую скриптами-ботами), они признали проблему с утра, не я один обращался. Помогло, по их совету, "Перезаказать данные заново". "До погашения" у фьючерсов стало отображать правильные цифры вместо нулей.
 
Цитата
green_X5 пишет:
Помогло, по их совету, "Перезаказать данные заново".
А переподключение к серверу не помогало?
Надо делать так, как надо. А как не надо - делать не надо.
 
Цитата
Серж пишет:
Цитата
green_X5 пишет:
Помогло, по их совету, "Перезаказать данные заново".
А переподключение к серверу не помогало?
Переподключал, меняя сервера, это не помогало. Только "Перезаказать данные заново".
 
Цитата
green_X5 пишет:
Переподключал, меняя сервера, это не помогало. Только "Перезаказать данные заново".
Если проблема более не повторяется, значит на сервере брокера была какая-то авария.
считаем тему закрытой.
 
Цитата
green_X5 пишет:
Переподключал, меняя сервера, это не помогало. Только "Перезаказать данные заново".
Вопрос к техподдержке: переподключение к серверу/другому серверу в течение текущей торговой сессии обновляет статические параметры бумаг?
Надо делать так, как надо. А как не надо - делать не надо.
 
Цитата
Серж пишет:
Вопрос к техподдержке: переподключение к серверу/другому серверу в течение текущей торговой сессии обновляет статические параметры бумаг
По умолчанию, да обновляет. Но брокер имеет возможность настроить сервера так чтобы не обновлялись
 
Цитата
Sergey Gorokhov пишет:
По умолчанию, да обновляет. Но брокер имеет возможность настроить сервера так чтобы не обновлялись
Если брокер использует такую возможность, то что является сигналом для смены статических параметров? Дата торгов?
Надо делать так, как надо. А как не надо - делать не надо.
 
Цитата
Серж пишет:
Если брокер использует такую возможность, то что является сигналом для смены статических параметров? Дата торгов?
Дата торгов не показатель, так как есть режимы которые торгуются и после полуночи. Сигналом для смены статических параметров является параметр "Идентификатор сессии" в информационном окне. Сам этот параметр меняется по ряду условий на сервере после рестарта.
 
Цитата
"Sergey Gorokhov пишет:
Цитата
Серж пишет:
Если брокер использует такую возможность, то что является сигналом для смены статических параметров? Дата торгов?
Дата торгов не показатель, так как есть режимы которые торгуются и после полуночи. Сигналом для смены статических параметров является параметр "Идентификатор сессии" в информационном окне. Сам этот параметр меняется по ряду условий на сервере после рестарта.
Добавлю, что очищать данные можно и после смены даты а не сессии.
Это настраивается в терминале меню Настройки -  Основные - Программа - Сохранение данных, секция "Очищать данные после смены даты"
  • «На локальной машине» – очищает в памяти данные предыдущей торговой сессии сразу после запуска программы, до установления связи с сервером. Используйте этот вариант, если нет необходимости получать информацию о торгах за предыдущий день перед началом торгов за текущий день.
  • «На сервере (при установлении связи)» – очищает данные предыдущей торговой сессии при появлении на сервере данных, относящихся к новой торговой сессии. Используйте это вариант, если информация о торгах принимается утром следующего дня (например, из-за существенной разницы в часовых поясах).
 
Цитата
Sergey Gorokhov пишет:
Цитата
green_X5 пишет:
Переподключал, меняя сервера, это не помогало. Только "Перезаказать данные заново".
Если проблема более не повторяется, значит на сервере брокера была какая-то авария.
считаем тему закрытой.
Сергей, если позволите, я против "считаем тему закрытой."
Я не знаю, но возьмусь предположить, что вы (разработчики) с целью оптимизации трафика между сервером и клиентским местом внесли жесткие или мягкие (на стороне сервера) настройки по паузе передачи данных, неизменяемых долгое время, например, как в данном случае, параметра "до погашения осталось". Как видите, инцидент показал, что клиенту это может выйти боком. По факту, клиент, получив однажды кривые данные, не получает автоматически исправленные, даже если они уже появились на сервере.
Это проблема, и решать её нужно. Вам.
 
Цитата
Sergey Gorokhov пишет:
Цитата
"Sergey Gorokhov пишет:
Цитата
Серж пишет:
Если брокер использует такую возможность, то что является сигналом для смены статических параметров? Дата торгов?
Дата торгов не показатель, так как есть режимы которые торгуются и после полуночи. Сигналом для смены статических параметров является параметр "Идентификатор сессии" в информационном окне. Сам этот параметр меняется по ряду условий на сервере после рестарта.
Добавлю, что очищать данные можно и после смены даты а не сессии.
Это настраивается в терминале меню Настройки - Основные - Программа - Сохранение данных, секция "Очищать данные после смены даты"
«На локальной машине» – очищает в памяти данные предыдущей торговой сессии сразу после запуска программы, до установления связи с сервером. Используйте этот вариант, если нет необходимости получать информацию о торгах за предыдущий день перед началом торгов за текущий день. «На сервере (при установлении связи)» – очищает данные предыдущей торговой сессии при появлении на сервере данных, относящихся к новой торговой сессии. Используйте это вариант, если информация о торгах принимается утром следующего дня (например, из-за существенной разницы в часовых поясах).
Не вариант решения проблемы. В указанном мною случае проблема висит в течении всего одного дня, в течении всей торговой сессии. Флагов проблемы нет, и инструментов для решения со стороны пользовательских скриптов клиента вы тоже не дали.
Развивать экстрасенсорные способности по определению поступ. параметров актуальности и соотв. биржевым данным не предлагайте, к тому же это не описать языком qLua.
Ещё раз обращу Ваше внимание ,в данном случае проблема не столько в кривых поступивших данных, сколько в необновлении их в терминале после обновления на сервере.
 
Цитата
green_X5 пишет:

Это проблема, и решать её нужно. Вам.
Описанной проблемы не должно было быть, есть специальная процедура восстановления в случае сбоев.
Если процедура выполняется то на клиентских терминалах данные перезакажутся.
Но все зависит от того какой это был сбой, и выполнил ли брокер указанную процедуру или нет, о чем нам неизвестно.
А если и не выполнил, у него могли быть на то причины.
В любом случае "сбой", это всегда авария и форс-мажор которого вообще не должно было быть, последствия которого заранее не известны. Со стороны клиента, исправлением этих последствий является возможность перезаказа данных, что и было выполнено.
 
Цитата
green_X5 пишет:
Развивать экстрасенсорные способности по определению поступ. параметров актуальности и соотв. биржевым данным не предлагайте, к тому же это не описать языком qLua.
боюсь со стороны сервера также нет такой возможности
 
Сергей, ответ "Не будем заниматься этой проблемой, потому что - не будем!" - тоже ответ, имеет право на жизнь. )
А вот "выполнил ли брокер процедуру - мы не знаем" и "какой именно форс-мажор имел место трудно установить" - не принимается. Я Вам дал описание проблемы, её дату, временной диапазон, назвал брокера, который имеет моё обращение (и не только моё), вроде как можете связаться с брокером (своим клиентом) и разобраться в проблеме.
И в третий раз укажу Вам на важность проблемы - Если данные исправились только после "Перезаказать данные с сервера", значит терминал не получал обновленные данные, когда они уже лежали (но почему-то не принимаются клиентским местом) на сервере. В результате клиентское место имеет неправильный параметр торгуемой бумаги, а именно "0", на не "28".
Была бы пустая строка "" или nil, мы бы могли обнаружить это скриптом.
Терминал отображал данные, не соотв. данным на сервере.

Если это проблема на серверной части, Вы наверное имеете возможность взаимодействовать и с их разработчиками. Подскажу адрес - support@quik.ru
 
Цитата
green_X5 пишет:
Сергей, ответ "Не будем заниматься этой проблемой, потому что - не будем!" - тоже ответ, имеет право на жизнь. )
А вот "выполнил ли брокер процедуру - мы не знаем" и "какой именно форс-мажор имел место трудно установить" - не принимается. Я Вам дал описание проблемы, её дату, временной диапазон, назвал брокера, который имеет моё обращение (и не только моё), вроде как можете связаться с брокером (своим клиентом) и разобраться в проблеме.
И в третий раз укажу Вам на важность проблемы - Если данные исправились только после "Перезаказать данные с сервера", значит терминал не получал обновленные данные, когда они уже лежали (но почему-то не принимаются клиентским местом) на сервере. В результате клиентское место имеет неправильный параметр торгуемой бумаги, а именно "0", на не "28".
Была бы пустая строка "" или nil, мы бы могли обнаружить это скриптом.
Терминал отображал данные, не соотв. данным на сервере.

Если это проблема на серверной части, Вы наверное имеете возможность взаимодействовать и с их разработчиками. Подскажу адрес - support@quik.ru
Критика это конечно хорошо, но есть ли у Вас конкрентое предложение в изменении текущего поведения?
 
Цитата
Sergey Gorokhov пишет:
Описанной проблемы не должно было быть, есть специальная процедура восстановления в случае сбоев.
Если процедура выполняется то на клиентских терминалах данные перезакажутся.
Данные на клиентских терминалах перезакажутся в какой момент? После переподключения к серверу или независимо от этого?
Процедура восстановления включает рестарт сервера?
Надо делать так, как надо. А как не надо - делать не надо.
 
Цитата
Sergey Gorokhov пишет:
есть ли у Вас конкрентое предложение в изменении текущего поведения?
Я думаю, это от вас должны исходить предложения, как должен повести себя робот в подобной ситуации. Поскольку ваш терминал вместо nil возвращает number, string или table, то иногда по возвращаемым значениям (как в этом случае) нельзя понять, является ли это значение корректным или имеет место сбой.
Надо делать так, как надо. А как не надо - делать не надо.
 
Цитата
Sergey Gorokhov пишет:
Цитата
green_X5 пишет:
Сергей, ответ "Не будем заниматься этой проблемой, потому что - не будем!" - тоже ответ, имеет право на жизнь. )
А вот "выполнил ли брокер процедуру - мы не знаем" и "какой именно форс-мажор имел место трудно установить" - не принимается. Я Вам дал описание проблемы, её дату, временной диапазон, назвал брокера, который имеет моё обращение (и не только моё), вроде как можете связаться с брокером (своим клиентом) и разобраться в проблеме.
И в третий раз укажу Вам на важность проблемы - Если данные исправились только после "Перезаказать данные с сервера", значит терминал не получал обновленные данные, когда они уже лежали (но почему-то не принимаются клиентским местом) на сервере. В результате клиентское место имеет неправильный параметр торгуемой бумаги, а именно "0", на не "28".
Была бы пустая строка "" или nil, мы бы могли обнаружить это скриптом.
Терминал отображал данные, не соотв. данным на сервере.

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

Если это проблема на серверной части, Вы наверное имеете возможность взаимодействовать и с их разработчиками. Подскажу адрес - support@quik.ru
Критика это конечно хорошо, но есть ли у Вас конкрентое предложение в изменении текущего поведения?
Да нет никакой критики. Есть просьба смоделировать проблемную ситуацию у себя. Наверняка у вас есть тестовая пара сервер-клиент. Перед "началом новой сессии" забейте фьючерсам "до погашения" ноль. Дайте соединение клиенту с сервером, клиент должен получить этот ноль. Затем, не разрывая соединения и не меняя сессии и даты торгов измените принудительно у сервера этот ноль на например 10. Посмотрите, изменились ли данные на клиентском месте. И как скоро изменились.
Вот и предложение.
Мы изучим этот вопрос. Постараемся в ближайшее время дать ответ.
 
Цитата
Sergey Gorokhov пишет:
есть специальная процедура восстановления в случае сбоев.
Если процедура выполняется то на клиентских терминалах данные перезакажутся.
Значит брокер в описываемой ситуации green_X5 не выполнил процедуру восстановления...

Цитата
Sergey Gorokhov пишет:
Данные перезакажутся после следующего подключения.
Да процедура включает рестарт сервера.
Т.е., максимум что мы (пользователи) можем сделать, это получать статические параметры при каждом вызове OnConnected()?
Кстати, верно ли, что в OnConnected() уже можно получить списки всех классов (getClassesList), бумаг (getClassSecurities), их статические параметры (getSecurityInfo), доступные для данного аккаунта (при условии правильной загрузки шлюзов брокером)?
Надо делать так, как надо. А как не надо - делать не надо.
 
Цитата
Старатель пишет:
Я думаю, это от вас должны исходить предложения, как должен повести себя робот в подобной ситуации. Поскольку ваш терминал вместо nil возвращает number, string или table, то иногда по возвращаемым значениям (как в этом случае) нельзя понять, является ли это значение корректным или имеет место сбой.
Сервер тоже этого не знает, и сообщить клиенту соответственно не может.
 
Я, как пользователь аки пенсионер не понимающий тонкостей взаимодействия клиент-сервер, вижу суть проблему такой:
Есть заявленная работа "клиента" - восстанавливать связь с сервером.
Если сервер во всю пашет, а клиент хромает - заявленная работа не фурычит. Что, где и когда - решать не удел пенсионера. Или я не вник в проблему ТС должным образом )
 
Цитата
сергей пишет:
Я, как пользователь аки пенсионер не понимающий тонкостей взаимодействия клиент-сервер
то Вы пользователь, то Вы не пользователь:
Скрытый текст
Так кто же Вы ? :)))
 
Цитата
Старатель пишет:
Кстати, верно ли, что в OnConnected() уже можно получить списки всех классов (getClassesList), бумаг (getClassSecurities), их статические параметры (getSecurityInfo), доступные для данного аккаунта (при условии правильной загрузки шлюзов брокером)?
Да это верно.
Цитата
сергей пишет:
Я, как пользователь аки пенсионер не понимающий тонкостей взаимодействия клиент-сервер, вижу суть проблему такой:
Есть заявленная работа "клиента" - восстанавливать связь с сервером.
Если сервер во всю пашет, а клиент хромает - заявленная работа не фурычит. Что, где и когда - решать не удел пенсионера. Или я не вник в проблему ТС должным образом )
Тема с восстановлением связи уже давно переросла в тему проверки данных
 
Цитата
green_X5 пишет:
Цитата
Sergey Gorokhov пишет:
Цитата
green_X5 пишет:
Сергей, ответ "Не будем заниматься этой проблемой, потому что - не будем!" - тоже ответ, имеет право на жизнь. )
А вот "выполнил ли брокер процедуру - мы не знаем" и "какой именно форс-мажор имел место трудно установить" - не принимается. Я Вам дал описание проблемы, её дату, временной диапазон, назвал брокера, который имеет моё обращение (и не только моё), вроде как можете связаться с брокером (своим клиентом) и разобраться в проблеме.
И в третий раз укажу Вам на важность проблемы - Если данные исправились только после "Перезаказать данные с сервера", значит терминал не получал обновленные данные, когда они уже лежали (но почему-то не принимаются клиентским местом) на сервере. В результате клиентское место имеет неправильный параметр торгуемой бумаги, а именно "0", на не "28".
Была бы пустая строка "" или nil, мы бы могли обнаружить это скриптом.
Терминал отображал данные, не соотв. данным на сервере.

Если это проблема на серверной части, Вы наверное имеете возможность взаимодействовать и с их разработчиками. Подскажу адрес - support@quik.ru
Критика это конечно хорошо, но есть ли у Вас конкрентое предложение в изменении текущего поведения?
Да нет никакой критики. Есть просьба смоделировать проблемную ситуацию у себя. Наверняка у вас есть тестовая пара сервер-клиент. Перед "началом новой сессии" забейте фьючерсам "до погашения" ноль. Дайте соединение клиенту с сервером, клиент должен получить этот ноль. Затем, не разрывая соединения и не меняя сессии и даты торгов измените принудительно у сервера этот ноль на например 10. Посмотрите, изменились ли данные на клиентском месте. И как скоро изменились.
Вот и предложение.
Здравствуйте,
Для анализа проблемы мы связались с Вашим брокером Промсвязьбанк
К сожалению по имеющейся информации и логам брокера нам не удалось установить причину произошедшего, ровно как и найти какие-либо следы "сбоя". Возможно это следствие недостатка информации.
Сообщите, точную дату и время когда наблюдалась проблема с трансляцией параметра "до погашения".
А также сообщите свой UID и ip адрес сервера брокера к которому Вы подключаетесь.
 
Цитата
Sergey Gorokhov пишет:
Цитата
green_X5 пишет:
Цитата
Sergey Gorokhov пишет:
Цитата
green_X5 пишет:
Сергей, ответ "Не будем заниматься этой проблемой, потому что - не будем!" - тоже ответ, имеет право на жизнь. )
А вот "выполнил ли брокер процедуру - мы не знаем" и "какой именно форс-мажор имел место трудно установить" - не принимается. Я Вам дал описание проблемы, её дату, временной диапазон, назвал брокера, который имеет моё обращение (и не только моё), вроде как можете связаться с брокером (своим клиентом) и разобраться в проблеме.
И в третий раз укажу Вам на важность проблемы - Если данные исправились только после "Перезаказать данные с сервера", значит терминал не получал обновленные данные, когда они уже лежали (но почему-то не принимаются клиентским местом) на сервере. В результате клиентское место имеет неправильный параметр торгуемой бумаги, а именно "0", на не "28".
Была бы пустая строка "" или nil, мы бы могли обнаружить это скриптом.
Терминал отображал данные, не соотв. данным на сервере.

Если это проблема на серверной части, Вы наверное имеете возможность взаимодействовать и с их разработчиками. Подскажу адрес - support@quik.ru
Критика это конечно хорошо, но есть ли у Вас конкрентое предложение в изменении текущего поведения?
Да нет никакой критики. Есть просьба смоделировать проблемную ситуацию у себя. Наверняка у вас есть тестовая пара сервер-клиент. Перед "началом новой сессии" забейте фьючерсам "до погашения" ноль. Дайте соединение клиенту с сервером, клиент должен получить этот ноль. Затем, не разрывая соединения и не меняя сессии и даты торгов измените принудительно у сервера этот ноль на например 10. Посмотрите, изменились ли данные на клиентском месте. И как скоро изменились.
Вот и предложение.
Здравствуйте,
Для анализа проблемы мы связались с Вашим брокером Промсвязьбанк
К сожалению по имеющейся информации и логам брокера нам не удалось установить причину произошедшего, ровно как и найти какие-либо следы "сбоя". Возможно это следствие недостатка информации.
Сообщите, точную дату и время когда наблюдалась проблема с трансляцией параметра "до погашения".
А также сообщите свой UID и ip адрес сервера брокера к которому Вы подключаетесь.
еще сообщите код инструмента и код класса на котором на котором была проблема с трансляцией параметра "до погашения".
Страницы: 1
Читают тему
Наверх