Signal refresh before P6 and pending-order sync in MT4

Этот документ фиксирует текущую архитектуру жизненного цикла сигнала до фактического достижения расчетной P6/CP и объясняет, как серверный пересчет связан с поведением MT4-советника.

Короткий ответ#

До фактического достижения P6 сигнал не считается замороженным.

Серверный расчет продолжает переоценивать его на новом правом крае графика, а MT4-советник регулярно подхватывает свежую версию сигнала, обновляет Candidates и проверяет, не устарели ли уже выставленные pending-ордера.

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

Основные файлы#

inc_calc_controls.php - серверный bar-driven расчет ApprReachedAt, CP_dist, обычных pst_ и NEXTpst_
multibroker/multitrading/MT4/MarketPawnsBot_III_NewMain2.mq4 - основной MT4-советник, цикл загрузки сигналов, Candidates, pending, сопровождение позиций
multibroker/multitrading/MT4/MarketPawnsBot_1.mqh - структура Signal и runtime-состояние TradeState

Что именно пересчитывает сервер до P6#

Bar-driven модель#

Серверная часть идет по барам слева направо и на каждом новом правом крае доопределяет состояние модели.

До достижения P6 особенно важны:

ApprReachedAt - бар достижения уровня подхода
CP_dist - текущее расстояние от CP до последнего бара
NEXT-параметры - online-ветка для последнего доступного бара

CP_dist считается как текущее расстояние от CP_bar до последнего бара расчета:

$controlParams['TRADE']['CP_dist'] = round($curBar - $CP_bar, 3);

Это означает, что при появлении нового бара сервер действительно получает новую bar-driven версию сигнала, даже если P6 еще не достигнута.

Что происходит с `NEXT`#

Когда расчет работает в online-режиме и доходит до последнего актуального бара, система формирует NEXT-ветку параметров.

Это не отдельный торговый сигнал в MT4-структуре, а серверный способ сохранить текущее состояние модели на последнем правом крае графика до появления следующего завершенного бара.

Что происходит с `pst_llRP6P6`#

Параметр pst_llR#P6 фиксирует расстояние между расчетной P6 и баром, на котором расчетная P6 была достигнута.

Его обычная версия создается в момент фактического достижения P6, чтобы не вносить look-ahead leakage в исторический расчет.

NEXTpst_llR#P6 существует как online-зеркало, но использует уже известный факт calcP6reached. Поэтому это не параметр, который должен свободно "плавать" до достижения P6; до фактического достижения P6 он просто еще не становится обычным торговым фактом.

Как MT4-советник получает новую версию сигнала#

Цикл работы#

Основной советник работает через OnTimer(), а не через OnTick().

На каждом штатном цикле он:

запрашивает свежую порцию сигналов с сервера
проверяет pending-ордера на актуальность
валидирует массив Candidates
добавляет новые сигналы
сопровождает уже открытые позиции

Именно поэтому до достижения P6 локальная копия сигнала в MT4 может обновляться несколько раз по мере того, как сервер отдает новую bar-driven версию.

Обновление `Candidates`#

Если по тому же model_id + set_id приходит новая версия сигнала, советник не держит старую копию в Candidates.

Он переносит в новый объект тот же number/slot, а затем заменяет старый элемент массива новой версией сигнала.

Практический смысл такой:

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

Как перепроверяются `pending`-ордера#

Execution contract#

Для уже выставленных pending-ордеров советник не сравнивает весь серверный Controls/NEXT-слепок.

Вместо этого он строит execution signature, то есть компактный "контракт исполнения" сигнала.

В эту сигнатуру входят только поля, которые реально влияют на постановку и сопровождение отложенного ордера, например:

tool, period, trade_type, cond2
sizeLevel, sizeTime
CP_lvl, CP_dist, start_, t4_lvl, t5_lvl
SL1, TP, trg, trl
minPL, lost_lvl, lost_bars, preappr_lvl
BumperLevel1, BumperLevel2, NN4Enabled, NN5Enabled, NN6Enabled
ev_score, entry_origin

Если свежий серверный сигнал по тому же model_id + set_id уже имеет другой execution contract, текущий pending-ордер считается stale:

stale pending удаляется
старая локальная версия сигнала убирается из Trades
новая версия затем может быть заново создана через обычный путь FindNewSignals() -> MPB_createOrders()

Что это означает practically#

До достижения P6 сигнал действительно может быть "переопределен" системой так, что это повлияет на уже выставленный pending-ордер.

Но перепроверка идет не по любому внутреннему постконтрольному параметру, а только по тем полям, которые входят в execution contract и реально используются советником.

Что не делает советник#

Открытые позиции не живут в том же refresh-контуре#

Когда pending уже активировался и позиция стала открытой, советник больше не использует тот же механизм stale-refresh.

Открытая позиция сопровождается через локальные структуры Trades[] и TradeState:

контроль закрытия
пересчет AMrealP6
обработка trg1..trg7 и trl1..trl7
bar-driven проверки NN4, NN5, NN6

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

`pst_llRP6P6` не является прямым EA-полем сигнала#

Структура Signal в MT4 не содержит отдельного поля pst_llRP6P6.

Поэтому изменение только этого параметра само по себе не заставит EA пересоздать pending-ордер и не приведет к пересмотру уже открытой позиции, если оно не отразилось в полях реального execution contract.

Итоговая модель#

До P6 архитектура работает так:

сервер bar-driven пересчитывает сигнал на новом правом крае графика
MT4-советник на очередном OnTimer() получает свежую версию сигнала
Candidates заменяются новой версией сигнала
pending-ордера сверяются по execution contract
при расхождении stale pending удаляется и может быть создан заново по новой версии сигнала

После открытия позиции архитектура меняется:

советник перестает использовать stale-refresh для этой сделки
сопровождение идет через локальное runtime-состояние Trades и TradeState
постконтроль и trailing работают через локальные bar-driven проверки, а не через полную замену сигнала с сервера

Практическая интерпретация для диагностики#

Если нужно понять, действительно ли новый бар на сервере мог повлиять на уже выставленный pending, следует проверять не только внутренние pst/NEXT-поля, а прежде всего фактические торговые поля сигнала:

изменился ли CP_dist
изменились ли start_, SL1, TP
изменились ли lost_lvl, lost_bars, preappr_lvl
изменились ли bumper / NN-флаги
изменился ли entry_origin

Если эти поля не изменились, то сам по себе server-side перерасчет модели еще не означает, что MT4-советник должен удалить и пересоздать уже выставленный pending.