Перехват запросов советника к серверу "на лету"

 
Возможно ли перехватывать запросы советника к терминалу, так сказать, "на лету", не дожидаясь их исполнения? Цель - максимально синхронно продублировать те же сигналы на второй терминал. Я видел варианты копировщиков, но там сигналы на второй терминал передаются только после их исполнения сервером на первом терминале, а так чтобы копировались до исполнения можно сделать?  У кого какие идеи,  варианты?
 
Ты сам-то хоть понял, чего спросил?
 
evillive: чтобы копировались до исполнения можно сделать?  У кого какие идеи,  варианты?
Если только помудрить что-то с машиной времени )))
 

Почему? Вроде все понятно.

Если я правильно понял, топикстартер хочет снимать сигналы с ведущего терминала в момент (или сразу же после) их отдачи советником (т.е. в момент отдачи приказа с ведущего терминала). А не после исполнения приказа сервером. Т.е. не ждать несколько лишних секунд.

 
Та это-то понятно. Можно сделать dll-ку, которая позволит перехватывать процессы, только толку-то от этого?
 
drknn:
Та это-то понятно. Можно сделать dll-ку, которая позволит перехватывать процессы, только толку-то от этого?

Вот именно... Сервер мастера отклонит сделку, а сервер ведомого откроет, а потом закроет. Убыток в размере спрэда!
 

Понятно... Ну я так и думал что, раз перехватывать процессы МТ4 не умеет, придётся мудрить сторонние приблуды.

KimIV:

Вот именно... Сервер мастера отклонит сделку, а сервер ведомого откроет, а потом закроет. Убыток в размере спрэда!
  Это только при пипсовке спрэдами :D
 
evillive:

Это только при пипсовке спрэдами :D

Стиль торговли не имеет значения...

Ещё вот такой случай. С мастера ушёл запрос. Ведомый тоже отправил. Сервер мастера тормозит и долго не выполняет торговый запрос, а сервер ведомого выполнил. Потом ведомый терминал смотрит, на мастере нет сделки, значит надо закрыть. 

 
KimIV:

Стиль торговли не имеет значения...

Ещё вот такой случай. С мастера ушёл запрос. Ведомый тоже отправил. Сервер мастера тормозит и долго не выполняет торговый запрос, а сервер ведомого выполнил. Потом ведомый терминал смотрит, на мастере нет сделки, значит надо закрыть. 


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

Задумка была в синхронном открытии рыночных сделок на ведомом терминале, отложки не проблема отсылать после подтверждения сервером как и в других копировщиках, решение о закрытии будет приниматься отдельно и никак не связано с мастером, то есть описанной ситуации где на мастере нет исполнения и на ведомом сделка закроется, не будет. На ведомом сделки будут закрываться локальным советником или вручную.
Ну если так, то в копировщиках (по крайней мере в моих) есть параметр, которых запрещает вход на ведомом по хУдшей цене, чем на мастере. На ведомом иногда даже удаётся зайти по лУчшей цене. Кроме того, отвязать закрытие от мастера тоже не составит труда.
 
evillive:
Возможно ли перехватывать запросы советника к терминалу, так сказать, "на лету", не дожидаясь их исполнения? Цель - максимально синхронно продублировать те же сигналы на второй терминал. Я видел варианты копировщиков, но там сигналы на второй терминал передаются только после их исполнения сервером на первом терминале, а так чтобы копировались до исполнения можно сделать?  У кого какие идеи,  варианты?

Конечно это можно реализовать.

Всего есть два очевидных варианта решения.

1) Перехват запроса на системном уровне тут одним MQL4 не обойтись.
2) Перехват запроса из тела советника, это актуально если нужно копировать сделки которые открывает советник.

С первым вариантом все понятно.. нужно организовать перехват запросов из терминала на торговый сервер, затем все дублировать на ведомый терминал.

Второй вариант реализуем на чистом MQL4.. относительно недавно реализовывал подобное на заказ.

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

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


Как это реализуется на MQL4(второй вариант решения)?

Пример:
//XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX
int Order()//некая функция открытия ордера внутри советника.
{
int t1,t2;

t1=OrderSend_v(Symbol(),OP_BUY,0.1,Ask,30,sl_r,tp_r,"",0,0,Blue);//перед реальной функцией открытия дублируем этот ордера на приемник(ведомый).
t2=OrderSend(Symbol(),OP_BUY,0.1,Ask,30,sl_r,tp_r,"",0,0,Blue);//реальная функция открытия.
}
//XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX

//XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX
int OrderSend_v(string symbol, int type, double lots, double price, int slippage, double stoploss, double takeprofit, string comment="", int magic=0, datetime expiration=0, color arrow_color=CLR_NONE)
{
int t;
//тут выполняем отправку приказа приемнику(ведомому).
}
//XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX

//ПОЛУЧАЕМ ОТПРАВКУ ПРИКАЗА В ПРИЕМНИК ОДНОВРЕМЕННО С ОТПРАВКОЙ ПРИКАЗА НА ГЛАВНОМ СЧЕТЕ.


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