Вы упускаете торговые возможности:
- Бесплатные приложения для трейдинга
- 8 000+ сигналов для копирования
- Экономические новости для анализа финансовых рынков
Регистрация
Вход
Вы принимаете политику сайта и условия использования
Если у вас нет учетной записи, зарегистрируйтесь
В общем, задача почти определилась.
Меня смущает,что, допустим, 5 советников будут передавать полный объем рабочих пакетов, если движок работает с шестым. Нужно на время запретить остальным пятерым передавать рабочую информацию. Пусть просто "слушают эфир".
Согласен. Это разумно.
Значит, они будут работать штатно, но записывать сообщения в ресурс не будут. Только в копию ядра параметров. А при подключении, запишут ядро параметров в ресурс и Движок его загрузит. После подключения, советник начнет записывать сообщения для Движка в ресурс сообщений.
Вопрос в подключении.
Движок выставляет малую строку-адрес всем советникам. Отзывается ядро в советнике с таким же адресом опознавания и автоматически начинается стандартная работа движок-советник. При переключении в движке на другой советник, движок переводит ядро советника, с которым работал в состояние ожидания адреса, как и другие советники в этот момент. В такой момент отцеплены все советники и ждут выставления движком другого адреса другого нужного движку советника.
Ядро нового советника откликается и переходит в состояние стандартной работы. До следующего посыла движком строки конца работы и перехода в состояние ожидания. Просто советники должны кроме стандартного обмена постоянно анализировать поток на появление в нем строки конца работы. В начале пакетов обмена должна стоять строка, указывающая кому адресован пакет передаваемый с движка. То ядро и принимает пакет управления и начинает отсылать пакеты своего состояния с заданной частотой.
Остальные ждут обращения к ним через уникальную для каждого советника строку опознавания. При переключении, движок посылает текущему советнику строку конца работы. Советник прекращает что-либо отсылать и переходит в состояние распознавания своей строки опознавания , являющейся одновременно запуском стандартной работы обмена с движком.
Вопрос в подключении.
Движок выставляет малую строку-адрес всем советникам. Отзывается ядро в советнике с таким же адресом опознавания и автоматически начинается стандартная работа движок-советник. При переключении в движке на другой советник, движок переводит ядро советника, с которым работал в состояние ожидания адреса, как и другие советники в этот момент. В такой момент отцеплены все советники и ждут выставления движком другого адреса другого нужного движку советника.
Ядро нового советника откликается и переходит в состояние стандартной работы. До следующего посыла движком строки конца работы и перехода в состояние ожидания. Просто советники должны кроме стандартного обмена постоянно анализировать поток на появление в нем строки конца работы. В начале пакетов обмена должна стоять строка, указывающая кому адресован пакет передаваемый с движка. То ядро и принимает пакет управления и начинает отсылать пакеты своего состояния с заданной частотой.
Остальные ждут обращения к ним через уникальную для каждого советника строку опознавания. При переключении, движок посылает текущему советнику строку конца работы. Советник прекращает что-либо отсылать и переходит в состояние распознавания своей строки опознавания , являющейся одновременно запуском стандартной работы обмена с движком.
C ресурсами несколько проще. Там адреса не нужно, только наименование ресурса. У вас получилась усложненная модель. Все проще.
Ядро - просто массив значений. Каждый советник записывает в него значения параметров элементов его GUI. Когда необходимо, советники будут сохранять копию ядра параметров в ресурс, а движок будет его читать и перерисовывать GUI.
В принципе, это простая задача, но в ней много маленьких нюансов. Например, сообщения о начале и прекращении общения с советником. Нужно только формат придумать.
Кстати, мне удалось убыстрить связь и уменьшить торможение. Но до конца причины торможения еще не понял. Оно появляется при перерисовке, но странность в том, что перерисовка сама по себе не тормозит. А перерисовка при общении через ресурс тормозит. Причина пока не ясна.
Какой-нибудь мониторинг временных затрат поставте. Что бы видеть, где тормозит. И как это объехать.
Может я и усложнил маленько. Я же не знаю, как у вас там внутри движка организовано. Просто логикой пользовался.
Какой-нибудь мониторинг временных затрат поставте. Что бы видеть, где тормозит. И как это объехать.
Может я и усложнил маленько. Я же не знаю, как у вас там внутри движка организовано. Просто логикой пользовался.
Логика приблизила вас к сути, и в общем, вы понимаете правильно.
Сегодня попробую разобраться в причинах торможения. Ясно следующее, - сама перерисовка не тормозит. Запись и чтение ресурса тоже. А вместе, - получается торможение.
Есть мониторинг, какая операция сколько длится? Они должны последовательно выполняться. В советнике они, снятие данных и отправка в движок выполняются с частотой, допустим 30мс. Когда выполняется отправка потока в движок, тот готов принять? Или чем он занимается?
Сейчас все проверяю.
Движок на частоте 30мс читает ресурс сообщений от советника, а советник, на той же частоте, читает ресурс сообщений от Движка. На этой же частоте, они оба записывают свои сообщения друг другу (если есть что записывать). Все это не вызывает торможения. Также, перерисовка сама по себе, не вызывает торможение.
Однако, торможение появляется, если комбинируются перерисовка и запись/чтение ресурса на стороне Движка. Причина пока непонятна. Выясняю.
Сейчас все проверяю.
Движок на частоте 30мс читает ресурс сообщений от советника, а советник, на той же частоте, читает ресурс сообщений от Движка. На этой же частоте, они оба записывают свои сообщения друг другу (если есть что записывать). Все это не вызывает торможения. Также, перерисовка сама по себе, не вызывает торможение.
Однако, торможение появляется, если комбинируются перерисовка и запись/чтение ресурса на стороне Движка. Причина пока непонятна. Выясняю.
Может рассоглассованость: и советник и движок, 1- оба передают друг другу, 2 - оба принимают, их OnTimer циклы не синхронизированны. Ждут момент случайной синхронизации нормальной работы. Может из-за этого?