Обсуждение статьи "Рецепты MQL5 — Сервисы"

 

Опубликована статья Рецепты MQL5 — Сервисы:

В статье описаны разносторонние возможности сервисов — таких MQL5-программ, для которых не нужен график привязки. Приводятся отличия сервисов от других MQL5-программ, подчёркиваются нюансы работы разработчика с сервисами. В качестве примеров читателю предложены различные задачи, охватывающие широкий спектр функционала, который может быть реализован в виде cервиса.

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

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

И добавим ещё немного красок. Если позиция в прибыли, то цвет фона графика будет светло-голубым, а если в минусе — светло-розовым. Нулевая прибыль  использует цвет лаванды.


Автор: Denis Kirichenko

 
Нужна возможность создания служб из ресурсов эксперта.
 
Anatoli Kazharski #:
Нужна возможность создания служб из ресурсов эксперта.

   +1

 

Спасибо за статью - было интересно!

Такой вопрос, как то можно оперативно - по факту открытия\изменения позиции\ордера на любом символе получать информацию?

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

Или лучше код встраивать в каждый советник?

 
Aleksey Vyazmikin #:

Спасибо за статью - было интересно!

Такой вопрос, как то можно оперативно - по факту открытия\изменения позиции\ордера на любом символе получать информацию?

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

Или лучше код встраивать в каждый советник?

Алексей, не получится. Ведь сервис, это как скрипт, с той лишь разницей, что запускается одновременно с запуском терминала…

Запустили терминал, сервис выпрыгнул, отработал и в тину…

Можно конечно запустить в бесконечном цикле, но на сколько это будет эффективно, решать самому…

 
Alexey Viktorov #:

Алексей, не получится. Ведь сервис, это как скрипт, с той лишь разницей, что запускается одновременно с запуском терминала…

Запустили терминал, сервис выпрыгнул, отработал и в тину…

Можно конечно запустить в бесконечном цикле, но на сколько это будет эффективно, решать самому…

С одной стороны не хватает OnTrade(), с другой стороны если сервис будет просто сводить ордера и писать в базу разрешенные операции, то может работать. Но опять же, актуален вопрос синхронизации. Для некритичных к задержке стратегий, работающих по открытию бара - вроде кажется реалистично так сделать. Через сервис можно торговать? Вроде не видно ограничений. Тогда можно от экспертов получать заявки, сводить их и самостоятельно торговать с заданной частотой.

 
Aleksey Vyazmikin #:

Спасибо за статью - было интересно!

Такой вопрос, как то можно оперативно - по факту открытия\изменения позиции\ордера на любом символе получать информацию?

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

Или лучше код встраивать в каждый советник?

Алексей, спасибо за мнение!

Хороший вопрос. Тут нужно взвесить все за и против. С одной стороны, как заметил коллега Alexey Viktorov, сервис для такой задачи нужно запускать в бесконечном цикле. Но с другой, сервис работает в фоне и сам пишет\читает из базы данных (БД). Если же в каждый робот добавлять возможность работы с БД, то необходимо понимать, что может быть конфликт синхронизации. Тут наверное поможет что-то вроде мьютекса.

Ну и советники могут моментально обрабатывать торговые события, а сервис - нет...

 
Aleksey Vyazmikin #:

Спасибо за статью - было интересно!

Такой вопрос, как то можно оперативно - по факту открытия\изменения позиции\ордера на любом символе получать информацию?

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

Или лучше код встраивать в каждый советник?

У меня свои виртуальные позиции каждый робот учитывает сам. О реальных, в принципе, и не знает. Единственное, тут проблема для MM с определением лота, но у меня фиксированный лот задаётся через параметры. Альтернативу фиксированному вижу только в выделении каждому роботу какого-то процента от депо.

 
А сервисам, КМК, очень не хватает обработки событий - OnTimer, OnTrade, OnTradeTransaction. OnDeinit бы тоже не помешал для штатного останова при закрытии терминала.
 
Denis Kirichenko #:

Алексей, спасибо за мнение!

Хороший вопрос. Тут нужно взвесить все за и против. С одной стороны, как заметил коллега Alexey Viktorov, сервис для такой задачи нужно запускать в бесконечном цикле. Но с другой, сервис работает в фоне и сам пишет\читает из базы данных (БД). Если же в каждый робот добавлять возможность работы с БД, то необходимо понимать, что может быть конфликт синхронизации. Тут наверное поможет что-то вроде мьютекса.

Ну и советники могут моментально обрабатывать торговые события, а сервис - нет...

А разве SQLite не умеет работать с очередью транзакций? Я с этим вопросом не разбирался, но Вы писали же статью, поэтому и спрашиваю :)

Писать можно в каждый раздел базы (отдельную таблицу), или даже каждый советник может создать свою базу, а сервис будет проверять наличие базы и подключать её для работы.

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

 
JRandomTrader #:

У меня свои виртуальные позиции каждый робот учитывает сам. О реальных, в принципе, и не знает. Единственное, тут проблема для MM с определением лота, но у меня фиксированный лот задаётся через параметры. Альтернативу фиксированному вижу только в выделении каждому роботу какого-то процента от депо.

Хочется универсальности, что бы набирать корзины советников с разной логикой. Если советник в собственном соку вариться, то да - там чуть проще - сам делал, правда экспериментально - без сохранения данных в файл/БД.