Albert Eritsyan (Все сообщения пользователя)

Здравствуйте Анастасия !
Речь, всего лишь, о предоставлении опции сохранения файлов alltrade.dat и info.log по путям, указанным пользователем, а не о некорректной работе терминала. Что касается размеров указанных файлов, они образуются при выполнении указанного Вами п. 1 в конце торгового дня, а не сразу же, т.е. постепенно возрастают по мере поступления информации в терминал пользователя.
Просьба зарегистрировать пожелание предоставления пользователю возможности выбора путей сохранения этих файлов без глобальных изменений кода Quik.

Разумеется об info.log говорить не приходится, какова логика логирования, и почему лог файл принимает такие размеры, не понятно. Именно поэтому и просьба дать возможность пользователю указать путь сохранения в другом месте, так как  размер info.log не предсказуем.

По факту на конец торгового дня Quik в RAM занял 1,5 Гб, alltrade.dat около 1.4Гб, info.log около 2,6 Гб. Как то странно проецируется alltrade в RAM, при проецировании столько памяти в RAM не должно было выделиться, а должны были выделиться только под нужные страницы файлов.
Данные по Quik 8.13.0.106. Такая же картина по другим версиям Quik.

Было бы здорово, если бы выбор списка инструментов по таблице обезличенных сделок можно было бы сделать через Lua script, а не вручную, тогда может быть поднятый вопрос на некоторое время был  бы отложен. Но, все равно, увеличивающийся объем сделок, требует коррекции подхода в поднятом вопросе.
Именно поэтому и предоставление опции выбора путей видится самым безобидным решением на данный момент..

Реально, куда больше времени уходит после чтения данных с дисков на синхронизацию и начало получение данных с сервера, вот тут-то info.log может разрастись до гигантских размеров. Пользователей же волнует суммарное время, а не время чтения с диска, так как им нужно синхронизированное поступление данных с сервера, последнее при переподключении терминала и превалирует над временем чтения с диска.
Но, воля Ваша, оценивайте как "странное" желание.

Это же, всего лишь временное решение проблемы, которую с неизбежностью придется решить в связи с возросшим объемом сделок, плюс подключение зарубежных бирж.
Речь, всего лишь о предоставлении возможностей сохранения этих файлов по указанным пользователем путям.
Не говоря уже о том, что всю таблицу обезличенных сделок держать в RAM, при условии уже их нахождения на HDD, ну просто незачем, в RAM можно держать только последнюю часть таблицы, при необходимости (т.е. обращении программы к прежним данным интрадей, их можно поднять с HDD).
В чем проблема то ?
В конечном случае по предложенному пусти для уменьшения трафика вообще нужно отключить получение информации о сделках, тогда на трафике точно можно сэкономить, но вопрос то был поднят совершенно иной, а именно для начала дать возможность сохранения этих файлов по путям, указываемым пользователем.
И речь не о жалобе на размеры служебных файлов, а о том как с ними оптимально работать практически не изменив код программы, ведь программа все равно получает путь сохранения служебных файлов. предоставление же опции для больших файлов, ну совершенно безвредная и малозначительная коррекция кода.

Добрый день Уважаемые разработчики !
При работе с Quik создаются файлы alltrade.dat (такой же по объему что и занимаемый Quik в RAM), а также info.log в связи с повышением объемов поступающей информации, размеры указанных файлов становятся значительными. Просьба предоставить возможность пользователям выбора различных путей сохранения для файлов alltrade.dat и info.log, особенно info.log который способен кратно превосходить по размеру размер alltrade.dat (непонятно почему не самоочищается). Данная опция обеспечит возможность расположения этих файлов на HDD, в то время как программа сама будет находиться на SSD (чтобы не затирать SSD временными большими файлами).
И еще одно пожелание, можно ли предусмотреть возможность автоуменьшения размера info.log без остановки работы программы ?
Таблица обезличенных сделок используется Lua scprit-ами и отключение с последующим включением только для того, чтобы визуально проконтролировать чрезмерные размеры info.log создают большие неудобства.
Указанные пожелания объективно диктуются возрастающим количеством сделок на бирже и реально востребованы.

Спасибо заранее.

Здравствуйте !
Пожалуйста, поделитесь alltrade.dat за 23.03.2021 по Quik 7.9 x 32 либо подскажите где можно скачать?

Здравствуйте Сергей!
Речь идет именно о первом варианте "Транзакций нет в принципе", как получить этот список, если он доступен? Если нет то просьба зарегистрировать пожелание по предоставлению доступа к нему, причем либо этот список либо обратный к нему "Транзакции в принципе разрешены" в зависимости от того который из них короче.

Прежде чем писать это проверьте там много случаев не срабатывания. И просьба на конкретный вопрос давайте конкретный ответ, а не ссылки на основы "единственно верного и правильного учения в МИРЕ".

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

Он статический в течение торговой сессии а то и нескольких, но Брокеры периодически его меняют. Но не так часто, чтобы речь шла о динамическом обновлении данного списка перед каждой транзакцией.

Замечательно, чтобы это сделать как раз и требуется получить список инструментов, с которыми транзакции возможны в принципе! О чем, собственно, и идет речь в рамках обсуждаемой темы.Если бы это было так то, вопроса как такового бы не стало. Но на самом деле Брокеры предлагают различные счета с различным покрытием доступных для транзакций инструментов у каждого типа счетов. Именно поэтому вопрос и возник.

Повторяю, речь идет не об отслеживании любого ограничения как такового, а только о получении списка инструментов с которыми транзакции возможны в принципе. Разумеется, названные Вами ограничения распространяются на именно этот список, как то не разумно ограничивать транзакции не возможные в принципе.
Названные вами причины контролируются Брокером на уровне претрейдконтроля, его никто не собирается обойти, да и вряд ли у кого получится.
Задачи контролировать со стороны клиента правильность работы претрейдконтроля которое, также склонен думать не должно быть бесплатным, но в рамках обсуждаемой темы такой задачи не ставилось.
А какая разница есть такая система на стороне клиента или нет? Ваш вопрос относится к работе претрейдконтроля Брокера.
Если Вам интересно, то обычно в таких случаях оставляют возможность закрывать открытые позиции, либо их принудительно полностью либо частично закрывают со ссылкой на соответствующий регламент, ведь речь идет о рисках.

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

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

Здравствуйте Сергей!
Речь идет не о любых ограничениях, а только об исключенных брокером вообще т.е. о Вашем первом варианте (транзакций нет в принципе). О втором случае речи вообще не идет.

Конечно наличие подобной функции LUA разрешит вопрос.
Можно будет всего один раз уточнить запреты Брокера и не высылать заведомо не исполняемые ордера. Тогда подобная причина отказа транзакции просто исчезнет. Ведь вопрос как раз в том что отсутствует специальный код отказа "Запрет Транзакции Брокером". Проверять выставленные ордера и анализировать причины отказа по любому придется, но с учетом запрещенных к торговле инструментов с аккаунта.

При этом динамического апдейта всех списков никто и не спрашивал, вообще, это статический список, обновляемый разве что, при реконнекте, ведь список датафида, который гораздо больше грузится именно так! Так, что никакой перегрузки трафика не должно возникнуть.

Относительно затронутого глубоко философского вопроса "Почему АРКА не должна.."
     Напомню, что КВИК является платной торговой платформой, поэтому АРКА ДОЛЖНА, способствовать максимальной оптимизации торговли, в частности, сообщив терминалу содержащуюся в КВИКЕ информацию, что транзакции с аккаунта запрещены Брокером. И это каких-то особых усилий не потребует, ни от АРКИ, и уж тем более от Брокера.

Вопрос можно поставить иначе, а именно, получить список  класс/инструмент по которым нельзя подавать ордера из-за ограничений заранее известных квику от брокера, либо передавать специальный код отказа в транзакции - "Ограничение операций Брокером". Понятно, что 100% гарантии исполнения ордера по реально доступному для транзакций инструментам никто не дает, из-за множества иных причин. Но и вопрос так не ставился, речь шла именно о доступном для транзакций, а не гарантированном к исполнению списке инструментов.
Согласитесь, Брокер может со временем вносить изменения в своих ограничениях на транзакции, причем через КВИК, а у пользователя отсутствует элементарная возможность узнать об этом через терминал КВИКА перед тем как выставить ордер. При этом Пользователь может всего лишь один раз перед торговой сессией уточнить ограничения по счету от Брокера и не тыркаться туда своими ордерами.
     Согласен, можно и каждый раз тыркаться ордерами, анализировать их, и т.д. и это сработает.
     По сути речь идет об уточнении ""политики партии" в вопросе что лучше нормально использовать терминал, получая доступ к содержащейся в нем информации, необходимой для трейдинга, или же "нежно, но фанатично надругаться над ним"?
У меня создается впечатление, что негласно установлено второе как основа в подходе к решению всех проблем.

Сергей, давайте зарегистрируем пожелание по добавлению в КВИК  возможности клиенту, не отправляя транзакцию, получать сведения о доступности конкретного инструмента для транзакций, например, при получении списка инструментов класса через getClassSecurities.
В моем понимании в КВИКе вся необходимая информация имеется, нужно только лишь предоставить их по запросу клиента. На мой взгляд для этой цели getClassSecurities удобнее всего использовать, хотя, конечно же, Вам виднее.

На счет:
Вы сами указали,что
     Sergey Gorokhov пишет:
Способов ограничить великое множество
так что предварительный выбор классов пользователем, может натолкнуться на ограничение Брокера по инструментам внутри класса, не говоря о том, что по разным счетам клиента у Брокера доступны разные классы и инструменты.
  Ведь речь идет о ситуации когда принято решение о входе в позицию, и оно исполняется по всем доступным счетам клиента, здесь-то и возникает обсуждаемый вопрос, а именно доступен ли данный инструмент с конкретных счетов для транзакций или нет?
Его можно решить и топорно (высылая ордера и дождавшись ответа пытаться догадаться от чего это вдруг отказ, и для убедительности послать вдогонку второй ... третий и т.п. пока не наступит "твердое убеждение...в единственно верном и правильном учении") или цивилизованно (имея предварительные сведения о возможность совершать транзакцию с инструментом и не напрягая клиента, не сервер, никому не нужными ордерами с последующим гаданием на гуще причин отказа).

Приведенный мной выше код и его результаты показали ошибочность такого подхода, так как в этом случае "как раз приглашают не в ту дырку" (см выше класс Опционов, когда они не доступны для торговли)Т.е. проверка наличия или отсутствия номера заявки и цифрового кода в скобках гарантия, что транзакцию отвергли по причине ограничений Брокера? Или возможны ситуации, когда Брокерские ограничения отсутствуют но отклик такой же?

Хотел также уточнить, а возможность доработки самого Квика, в плане предоставления клиентам списка доступных для транзакций инструментов в принципе не выполнима? Ведь это избавит от необходимости нагружать КВИК подобного рода проверочными ордерами.

Здравствуйте Сергей!
То есть если я правильно понял, в первом случае речь идет о "глубоко научном методе тыка", исключая возможность оптимизации круга инструментов (исключив не доступные для транзакций) количество лотов в ситуации, когда нужно быстро определиться?
А втором случае есть какие либо специальные коды отказов в транзакции (либо четко ограниченный круг таковых, обусловленных именно наличием такого рода ограничений)?

Ну, а как вообще терминал узнает, что доступно,например, для датафида? Так и может узнать какие инструменты доступны для торговли. Ведь брокер подключается к КВИК серверу через Брокерский КВИК, вносит туда ограничения и к нему уже и подключаются терминалы клиентов брокера, так что информация о доступности для транзакции конкретного инструмента в самом КВИКЕ имеется. Вопрос заключается каким именно способом его получить.

Ну есть же список инструментов с датафиде Квика (через getClassesList и getClassSecurities), почему бы и не быть такому списку по доступным для транзакциям инструментам? иначе можно было и не предоставлять указанные функции, ведь трейдер знает все (чем, как и когда торговать).
Что касается ограничений, то они вводятся брокером также в через Квик, так что предоставить такую информацию пользователю КВИКА, заявляющего себя в качестве торговой платформы, само собой должно подразумеваться.
Относительно, решаемой задачи, она не совершенно конкретная, если имеются несколько счетов у одного брокера (как указано в названии этой темы) то вопрос абсолютно не праздный и не абстрактный, а более чем конкретный, неужели трейдер должен наизусть помнить на каких счетах какие инструменты доступны?
Задача в том, что при открытии позиций по инструменту, код самостоятельно решал такую рутинную задачу как определение по каким счетам клиента и в каком количестве открывать позиции (разумеется если они доступны для транзакций с этих счетов), а не уповал на "всезнающего" трейдейра, "подталкивающего" код в нужный момент, опережая код ручными манипуляциями через GUI, и уж тем более "не долбил" терминал заранее не исполняемыми ордерами.
Это становится реальной потребностью при наличии нескольких счетов у брокера или брокеров, так что речь не о создании суперботов для очередных "космических войн".

Этот способ себя не оправдывает, вот код для тестирования

в результате на счете пониженного ГО (брокер БКС), где брокером запрещены операции с опционами выдается следующее:

SPBFUT; PSFUT; SPBOPT; PSOPT; OPTEXP; FUTARENA; PSFUTARENA; FUTSPREAD; PSFSPREAD

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

Уважаемые разработчики, подскажите, пожалуйста, как получить список инструментов доступных для транзакций, с учетом ограничений брокера по различным счетам. Например, есть счета по торговли на ММВБ и ФОРТС, но в различных режимах (как то, единый, на котором учитываются разнонаправленные позиции при расчете ГО, или разные коэффициенты предоставляемых брокером плеч и пр.)